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ABSTRACT 


Strategic  Mobility  21  (SM21)  is  a  Congressionally  mandated  and  independently  funded  applied 
research  program  through  the  Department  of  Defense  (Office  of  Naval  Research).  The  program 
is  conducted  under  the  auspices  of  the  California  State  University  -  Long  Beach  Foundation,  a 
government-industry  academic  collaborative  enterprise.  This  design  document  supports  the 
SM21  efforts  in  developing  a  dual-use  multi-modal  node  located  at  the  Southern  California 
Logistics  Airport  in  Victorville,  California  that  will  be  supported  by  an  Integrated  Tracking 
System  (ITS).  In  the  context  of  the  SM21  program,  dual-use  technology  is  defined  as  serving 
both  the  commercial  and  military  sectors.  This  ITS  design  document  identifies  the  technical  and 
functional  requirements  for  developing,  procuring,  and  integrating  components  of  an  ITS  capable 
of  supporting  an  inland  regional  port,  multi-modal  operating  software  system.  It  is  not  intended 
to  identify  all  the  systems  that  will  compose  the  end  state  deployment  of  the  SM21  developed 
ITS  or  multi-modal  operating  system.  The  design  document  supports  the  development, 
deployment,  and  testing  of  an  ITS  based  on  a  Service  Oriented  Architecture  (SOA)  that  will 
enable  efficient  node  and  individual  terminal  operations  by:  optimizing  logistics  flows;  helping 
to  maintain  desired  productivity;  and  providing  high  service  quality  to  strengthen  customer 
relationships  through  up  to  the  minute  visibility  of  shipments  and  quick  turn  times. 
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1.0  Background 

This  document  defines  the  design  initial  operating  capabilities  (IOC)  for  the  Joint  Deployment 
and  Distribution  Support  Platform  (JDDSP)  Integrated  Tracking  System  (ITS)  that  will  support 
the  flow  of  freight  to  and  from  the  Southern  California  Logistics  Airport  (SCLA)  located  in 
Victorville,  California.  The  ITS  will  be  integrated  with  the  Inland  Port-Multi-Modal  Terminal 
Operating  System  (IP-MTOPS)1.  The  design  supports  a  stepwise  (incremental)  development 
and  deployment  effort  that  will  lead  to  the  IOC,  as  defined  in  this  document,  within  a  two  year 
program  period.  This  design  concept  integrates  Contract  Line  Item  Numbers  (CLIN)2  0009  Joint 
Data  Standard  and  Communications  Protocol;  CLIN  0010,  the  Regional  Wireless  Network 
Design;  and  CLIN  0012,  the  Regional  IT  Data  Network,  into  a  single  product  design  -  the 
JDDSP-ITS3. 

The  ITS  will  support  the  dual-use4  concepts  defined  in  the  Strategic  Mobility  21  (SM21)  Joint 
Operational  Concept  Document  (JOCD)  along  with  the  initial  operating  capabilities  defined  in 
the  SM21  Initial  Capabilities  Document  (ICD).  The  SM21  Program  Management  Plan  (PMP) 
with  the  Technical  Plan  Annex  governed  the  development  of  this  document. 

SM21  is  a  program  chartered  by  Congress  to  develop,  demonstrate,  and  deploy  the  concepts 
embodied  in  the  JOCD  and  ICD  at  the  former  George  Air  Force  Base  in  Victorville,  California. 
SM21  is  working  with  the  Southern  California  Logistics  Airport  Authority  (SCLA),  a  public- 
private  partnership,  charged  with  development  of  the  former  DOD  site  for  dual  military  and 
commercial  use  purposes. 

The  overall  SM21 -JDDSP  architecture  is  a  system-of-systems.  The  enterprise  architecture  is 
currently  under  study  within  several  ongoing  SM21  tasks  and  will  incrementally  evolve  during 
the  follow-on  efforts.  The  ITS  development  described  in  this  document  is  designed  to  evolve  as 
one  of  the  subordinate  system-of-systems  within  the  SM21 -JDDSP  enterprise  architecture. 
Specifically,  in  the  near  term  the  ITS  will  support  the  prototype  concept  embodied  in  the  IP- 
MTOPS  more  fully  described  within  this  document. 

1.1  The  Strategic  Mobility  21  Objective  and  Mission 

The  ITS  must  support  the  SM21  objective,  which  is  to  integrate  the  physical  components 
(system-of-systems)  of  an  Agile  Port  System  (APS)  to  support  both  commercial  and  military 
goods  movement  requirements  within  the  Southern  California  regional  context. 

The  physical  components  of  an  Agile  Port  System  (APS)  include: 

1 .  An  efficient  marine  terminal  measured  by  its  capability  to  accommodate  both  military 
and  commercial  goods  movement  with  minimal  disruption  between  one  and  another. 


1  The  Inland  Port  Management  Information  System  (IP-MTOPS)  will  be  developed  by  the  Strategic  Mobility  21 
program  to  support  the  Southern  California  Logistics  Airport  (SCLA)  and  the  Joint  Deployment  and  Distribution 
Support  Platform  as  defined  in  the  JDDSP  Multi-Modal  Terminal  Software  Specification. 

2  CLIN  Titles  are  as  provided  in  the  Office  of  Naval  Research  provided  Statement  of  Work. 

3  Hereafter  in  this  document  referred  to  as  the  ITS. 

4  The  term  dual-use  refers  to  the  use  of  the  ITS  by  both  the  commercial  and  military  sectors. 
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2.  An  inland  staging  area  or  transfer  facility  capable  of  performing  most  functions 
of  a  marine  terminal  except  berth  operations. 

3.  A  dedicated  surface  transportation  link  such  as  short  haul  rail  or  dedicated  truck 
lanes. 

4.  An  information  architecture  integrating  and  synchronizing  the  operation  of  the 
other  system  components. 

SM21  uses  the  APS,  as  defined  by  the  Center  for  the  Commercial  Deployment  of 
Transportation  Technologies  (CCDoTT),  as  the  physical  reference  model  for  the  JDDSP  and 
the  subordinate  ITS.  The  SM21  program  developed  JDDSP  at  SCLA  will  specifically  provide 
the: 

•  Integrating  information  management  system  for  the  dual-use  APS  and 

•  Physical  support  required  for  inland  staging  and  transfer  including  most  functions  of  a 
marine  terminal  except  berth  operations. 

The  JDDSP  has  been  defined  as  a  regional  multi-modal  and  intermodal  inland  port  but  more 
specifically  as  a  regional  multi-modal  logistics  airport.  The  integrating  information 
management  system  includes  both  the  ITS  and  the  IP-MTOPS  as  components  within  a  Service 
Oriented  Architecture  (SOA). 

1.2  ITS  Development  Approach  and  Team  Members 

The  approach  to  be  taken  by  SM2 1  with  our  selected  team  members  during  the  development  of 
the  ITS  development  process  can  be  described  in  simple  terms:  “Talk  a  little,  model  a  little,  learn 
a  lot”.  In  order  to  enable  this  incremental  development  process  we  have  established  an  initial  list 
of  stakeholders  and  team  members  to  collaborate  with  SM21  on  the  discovery,  development  and 
deployment  of  the  ITS  initial  operating  capability. 

In  addition  to  the  SM21  Team  Members,  government,  academic,  and  industry  partners  will 
collaborate  on  the  overall  ITS  development,  testing,  and  demonstration.  Major  importers  and 
exporters  through  Southern  California  will  be  designated  to  support  the  discovery  and  analysis 
associated  with  the  identification  and  validation  of  commercial  shipment  requirements  and  will, 
as  practical,  participate  in  technology  and  process  experimentation. 

Dole  Foods,  the  fifth  largest  importer  through  Southern  California,  will  provide  initial  testing 
support  for  the  ITS.  The  process  will  begin  with  the  integration  of  the  Dole  U.S.  Customs  and 
Border  Protection,  Automated  Manifest  System  (AMS)  data  with  the  SM2 1  incidence  of  the 
Trade  Corridor  Operating  System  (TCOS).  The  AMS  data  will  be  used  to  test  the  SM21 
Experimental  Database  developed  as  a  part  of  CLIN0009  and  the  Web  Portal  or  IP-MTOPS 
interface  described  in  more  detailed  in  the  following  sections  of  this  document.  After  the 
completion  of  the  initial  tests,  and  the  deployment  of  the  basic  ITS  system,  Dole  and  SM21  will 
continue  to  evaluate  capabilities  required  to  fill  the  gaps  in  the  Dole  supply  chain  visibility  and 
management  systems. 


2 


Integrated  Tracking  System  Analysis  &  Concept  Design 


In  addition  to  Dole  Foods,  Rubbermaid,  which  currently  operates  a  distribution  center  at  the 
SCLA,  will  participate  in  experimentation  more  focused  on  the  IP-MTOPS  development. 
However,  like  Dole,  Rubbermaid  will  also  participate  in  experimentation  related  to  closing  the 
information  gaps  that  exist  within  their  regional  supply  chain  visibility  and  management  systems. 
The  later  experimentation  will  be  a  direct  part  of  the  ITS  described  in  this  document. 

In  addition  to  commercial  partners,  the  ITS  will  support  local,  regional,  state,  and  federal 
government  agencies.  The  primary  regional  government  participation  will  be  with  the  Southern 
California  Association  of  Governments  (SCAG),  a  Metropolitan  Planning  Organization  (MPO). 
Figure  1  below  provides  an  overview  of  the  geographical  area  of  responsibility  for  SCAG. 


Southern  California  Association  of  Governments 

(SCAG) 


SCAG  Region 


SCAG  is  the  MPO  for  six 
Southern  California  counties: 

-  Los  Angeles,  Orange, 
Ventura,  Imperial,  Riverside, 
and  San  Bernardino. 

The  region  includes  187  cities 

The  Nation’s  second  largest 
MPO  by  population  and  the 
largest  MPO  by  land  area. 


Figure  1:  Southern  California  Association  of  Governments 


At  the  federal  level,  both  the  Department  of  Defense  and  the  Department  of  Transportation 
Maritime  Administration  (MARAD)  will  participate  in  early  ITS  testing.  The  initial 
comprehensive  federal  test  and  demonstration  of  the  ITS  capabilities  is  designed  to  demonstrate 
the  use  of  the  ITS  in  environments  outside  of  Southern  California.  This  test  will  be  conducted 
with  the  US  Transportation  Command  and  the  Port  of  Tacoma  in  the  Pacific  Northwest  during  a 
major  military  force  deployment.  The  ITS  initial  operating  capability  will  also  support  the  joint 
SM21  and  MARAD  project  designed  to  define  and,  as  appropriate,  develop  and  demonstrate  an 
in- gate/out-gate  appointment  system.  The  approach  for  the  MARAD  sponsored  project  is  to 
define  the  system  architecture  and  the  associated  business  practices  and  then  deploy  the  system 
for  limited  testing  within  Southern  California.  As  previously  noted,  a  key  component  of  this 
system  will  be  the  incorporation  of  the  SM21  ITS. 
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1.3  The  SM21  Operational  View 

Figure  2  below  is  the  SM21  Enterprise  Operational  View-1,  developed  using  the  Department  of 
Defense  Architecture  Framework  (DoDAF),  which  was  used  as  one  of  the  frameworks  for 
development  of  the  SM21  enterprise  architecture  (EA).  The  OV-1  is  a  high  level  operational 
concept  graphic  and  textual  description  of  the  SM21  operational  concept. 
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Figure  2:  Strategic  Mobility  21  Operational  View  1 


The  ITS  Operational  View  is  further  described  in  the  OV-1A  Diagram  provided  below  in  Figure 
2.  The  ITS  focuses  on  the  integration  of  the  event  data  represented  by  the  blue  ovals  on  the  far 
left  of  the  OV-1  Diagram  and  integrates  this  event  data  with  the  JDDSP  IP-MTOPS  represented 
by  the  red  circle  in  the  center  of  the  OV-1  Diagram.  The  ITS  event  data  requirements  will  be 
defined  by  the  operational  system  requirements  (dark  blue  inner  ring  surrounding  the  JDDSP  IP- 
MTOPS)  and  the  DoD  capability  concept  represented  by  the  lighter  blue  outer  ring  surrounding 
the  IP-MTOPS.  Additional,  the  JDDSP  military  and  commercial  potential  customers  depicted  on 
the  far  right  of  the  OV-1  Diagram  define  the  overall  JDDSP  required  capabilities. 
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2.0  ITS  Reference  Models 

The  ITS  developed  will  follow  several  reference  models  to  develop  the  internal  system-of- 
sy stems  architecture: 

•  Asa  component  in  the  SM21  EA  systems-of-systems  architecture,  the  ITS  will 
reference  the  Federal  Enterprise  Architecture. 

•  The  physical  reference  model,  as  previously  described,  is  the  CCDoTT  Agile  Port 
System 

•  The  ITS  system  development  will  be  guided  by  the  OASIS  Reference  Model  described 
within  this  section. 

2.1  Federal  Enterprise  Architecture  Reference  Models 

The  SM21  Enterprise  will  use  the  Federal  Enterprise  Architecture  (FEA)  collection  of 
interrelated  “reference  models”  initially  designed  to  facilitate  cross-agency  analysis  and  the 
identification  of  duplicative  investments,  gaps,  and  opportunities  for  collaboration  within  and 
across  Federal  Agencies.  In  the  near  term  the  FEA  will  not  be  referenced  for  the  ITS  initial 
operating  capability;  however,  in  working  within  the  overall  SM2 1  EA,  the  ITS  effort  will 
ultimately  be  guided  by  the  FEA.  A  detailed  description  of  the  FEA  can  be  found  at  the  E-Gov 
Web  page:  http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html. 

2.2  Physical  Reference  Model  -  Agile  Port  System 

The  ITS  will  be  follow  the  CCDoTT  Agile  Port  System  physical  reference  model  as  a  part  of  the 
initial  operating  capability  development.  The  first  full  test  of  the  ITS  will  occur  as  a  part  of  the 
demonstration  of  the  Agile  Port  System  in  the  Pacific  Northwest.  The  Agile  Port  System  was 
described  in  prior  sections.  The  reference  documentation  is  available  on  the  CCDoTT  Project 
Results  Website  within  several  files  related  to  the  Pacific  Northwest  Agile  Port  Analysis  and 
Demonstration:  http://www.ccdott.org/content/DS  fr.html. 

2.3  Service  Oriented  Architecture  Reference  Model 

The  deployment  of  the  ITS  and  the  overall  IP-MTOPS  will  employ  a  stepwise  deployment 
process  that  will  ensure  early  operating  capability  in  the  near  term  and  in  the  long  term  a  state  of 
the  art  Service  Oriented  Architecture  (SOA)  framework.  The  SOA  concept  has  received 
significant  interest  within  the  software  design  and  development  community,  which  has  resulted 
in  the  proliferation  of  many  conflicting  definitions  of  SOA.  To  mitigate  this  problem,  the  SM21 
program  has  selected  a  SOA  reference  model  developed  by  OASIS  (Organization  for  the 
Advancement  of  Structured  Information  Standards),  a  not-for-profit,  international  consortium 
that  drives  the  development,  convergence,  and  adoption  of  e-business  standards.  Whereas  SOA 
architectural  patterns  (or  reference  architectures )  may  be  developed  to  explain  and  underpin  a 
generic  design  template  supporting  a  specific  SOA,  a  reference  model  is  intended  to  provide  an 
even  higher  level  of  commonality,  with  definitions  that  should  apply  to  all  SOA5. 

The  selected  reference  model  is  an  abstract  framework  for  understanding  significant 
relationships  among  the  entities  of  the  SCLA-JDDSP.  It  enables  the  development  of  a  specific 


5  Reference  Model  for  Service  Oriented  Architecture  1.0,  Public  Review  Draft  1.0,  OASIS,  10  Feb  2006,  page  4 
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architecture  using  consistent  standards  or  specifications  supporting  the  SCLA-JDDSP  Business 
Community.  For  additional  background  and  model  information,  please  refer  to  the  complete 
reference  model  documentation,  which  is  available  at  the  SM21  PMIS  or  at  http://www.oasis- 
open.org/committees/tc  home.php?wg  abbrev=soa-rm. 

The  SM2 1  program  goal  for  using  this  reference  model  is  to  define  the  central  concepts  of 
service  oriented  architecture,  and  establish  a  vocabulary  and  a  common  understanding  of  SOA 
for  all  program  stakeholders  both  internal  and  external.  It  will  provide  a  “normative  reference” 
that  will  remain  relevant  throughout  the  SM21  SOA  stepwise  development  and  implementation, 
irrespective  of  the  many  future  technology  evolutions  that  will  influence  SOA  deployment. 
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Figure  3:  Relationship  of  the  Reference  Model  to  Other  Work 


The  concrete  ITS  and  overall  IP-MTOPS  architecture  will  be  developed  using  the  requirements 
identified  in  this  document.  The  SM21  supported  ITS  and  IP-MTOPS  Architecture  development 
will  not  be  done  in  isolation  but  will  account  for  the  goals,  motivation,  and  requirements  that 
define  the  actual  problems  or  gaps  being  addressed  in  both  the  commercial  and  military  sectors. 


6  Oasis  Reference  Model  for  Service  Oriented  Architecture  1.0,  10  February  2006;  Figure  1,  page  5 
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3.0  Overview  of  the  ITS  Analysis  and  Concept  Design 

This  document  focuses  on  the  concepts  and  requirements  for  the  ITS  and  the  deployment  of  an 
initial  operating  capability  depicted  below  in  the  SM21  OV-1A  diagram.  The  SM21  JDDSP 
system  of  systems  enterprise  architecture,  depicted  above  in  the  OV-1  Diagram  (Figure  2),  will 
be  incrementally  developed  using  existing  commercial  off  the  shelf  (COTS)  software  and  legacy 
DoD  information  management  systems.  The  SM21  EA  is  designed  to  evolve  into  a  Service 
Oriented  Architecture  (SOA).  The  ITS  will  be  the  first  increment  of  the  SM21  EA  developed. 

As  a  subordinate  component  of  the  SM21  EA,  the  ITS  will  also  be  incrementally  developed.  The 
ITS  will  be  developed  and  updated  through  the  continuous  integration  of  required  event  data 
from  various  forms  of  Automatic  Identification  and  Data  Capture  (AIDC)  technologies  and  data 
interchange  formats  and  protocols. 


Strategic  Mobility  21  Operational  View  1A 

Automatic  Identification  and  Data  Capture  (AIDC)  Technology  Integration 


Trade  Corridor  Operating  System 


Note:  This  is  an  illustrative  concept  diagram.  Firewalls  and  other  details  are  omitted  from  the  depiction 

Figure  4:  SM21  OV-1A  Automatic  Identification  and  Data  Capture  Technology  Integration 

Initially  Dole  Automated  Manifest  Data  will  be  integrated.  This  initial  event  data  integration 
will  be  followed  by  AIDC  event  data  including  RFID  and  bar  codes  but  will  be  extensible  to 
other  technologies  including  biometrics,  magnetic  stripes,  OCR,  smart  cards,  cell  phone  tracking, 
802. 1 1  network  presence  tracking,  and  voice  recognition.  The  SOA  design,  when  fully 
implemented,  will  support  the  acquisition  of  information  from  AIDC  readers,  aggregation  of  the 
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information  from  disparate  AIDC  technologies,  and  the  provisioning  of  common  location-based 
logistics  services  including  asset  location  and  cargo  tracking.  In  particular,  a  dual-use  surface 
transportation  asset  and  cargo  tracking  capability  for  tracking  both  transportation  assets  and 
individual  cargo  shipments  will  be  studied.  AIDC  information  should  be  available  from  users  of 
the  JDDSP,  terminal  tracking  systems,  and  regional  tracking  systems  and  can  be  supplemented 
with  information  from  other  sources  such  as  EDI  and  Web  Form  input.  Figure  3  above  depicts 
the  initial  flow  of  AIDC  information  through  the  ITS  to  the  JDDSP  IP-MTOPS.  This 
configuration  is  only  established  for  early  testing  and  experimentation.  The  objective  system 
deployment  is  depicted  in  Figure  7,  the  SM21  OV-1B  View. 

During  the  early  testing  of  the  ITS,  the  SM21  Tracking  and  Experimentation  Database7, 
developed  by  SM21  (CEIN009),  will  be  employed  and  refined  as  required.  The  information 
processed  through  TCOS  to  the  database  will  be  accessed  by  IP-MTOPS.  IP-MTOPS  is 
currently  in  the  early  stages  of  design  development. 

In  the  typical  case,  items  will  be  “identified”  by  their  association  with  AIDC  technologies  such 
as  RFID  tags  or  bar  codes.  The  identified  items  may  be  assets  -  including  conveyances  such  as 
rail  cars,  tractors,  and  chassis  -  individual  items  of  cargo,  collections  of  items  in  either  some 
form  of  packaging  (box,  pallet,  etc.),  or  shipping  containers.  An  association  is  made  between  the 
AIDC  information  and  the  item  it  identifies  (often  by  using  an  AIDC  reader  to  read  the  AIDC 
information  associated  with  the  item  and  then  combining  that  information  with  an  application- 
specific  identification  of  the  item)  and  this  identification  is  stored  in  a  dataset.  Fogistics  systems 
then  use  the  associations  stored  in  systems  such  as  IT-MTOPS  along  with  reads  reported  by 
AIDC  readers  to  facilitate  valued-added  services  such  as  asset  location,  cargo  tracking,  ordering, 
shipping,  and  stock  management.  The  key  gap  that  the  ITS  design  will  fill  is  the  integration  of 
information  from  multiple  sources  of  AIDC  and  EDI  data. 

This  ITS  study  performed  preliminary  evaluations  of  active  RFID  tag-based  technology 
developed  by  Savi.  The  Savi  system  is  currently  being  used  as  a  component  of  the  Department 
of  Defense’s  In  Transit  Visibility  (ITV)  System  and  will  provide  input  to  the  ITS.  While  SAVI 
tag  readers,  SAVI  tag  programmers,  and  the  DoD  ITV  system  will  be  sources  of  data  for  the  ITS, 
other  selected  RFID  technology  has  been  reviewed  for  specific  uses.  The  other  systems 
reviewed  include  WhereNet  and  TransCore  wireless  technology.  All  three  currently  have 
operating  applications  in  the  Southern  California  Region  that  will  directly  or  indirectly  provide 
information  to  the  ITS  through  the  Trade  Corridor  Operating  System  (TCOS)  developed  by 
TransCore.  TCOS  will  enable  the  capture  of  information  from  various  RFID  tags  and  other 
tracking  systems.  TCOS  is  described  in  more  detail  within  this  document. 

Figure  4  below  provides  the  UME  class  model  illustrating  the  key  AIDC  tracking  concepts  in 
end-state  or  full  operating  capability  (FOC  of  the  SM21  ITS). 


7  The  database  design  is  document  in  the  SM21  CLIN0009  Report,  “Development  of  Joint  Data  Standards  and 
Communication  Protocols  in  An  Integration  Container  Tracking  System,”  March  15, 2007 
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class  AIDC  Model  ^ 


- 1\ 

This  diagram  is  a  class  model  describing  how 
Automatic  Identification  and  Data  Capture  (AIDC)  is 
used  in  logistics  systems.  It  is  intended  to  cover  both 
the  "tracking"  functionality  of  interest  in  this  year's 
program  as  well  as  the  broader  requirements  of 
Sense  and  Respond  Logistics  (SR L)  in  general. 


Figure  5:  SM21  AIDC  Class  Model 
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The  expected  benefits  of  the  integration  of  AIDC  to  the  ITS  are  outlined  in  Table  1  below. 


Expected  Benefits  of  the  Integrated  Tracking 

Stakeholder 

Expected  Benefit 

Shippers/Consignees 

Pickup/delivery  notification 

Improved  accuracy  of  logistics  information 

Container  and  truck  location  at  key  points 

Ocean  and  Rail  Carriers 

Pickup/delivery  notification 

Improved  accuracy  of  logistics  information 

Enhanced  customer  service 

Freight  Forwarders/Brokers 

Reduced  paperwork 

Improved  communication  with  Customs 

Reduced  cost  due  to  improved  truck  operations 

Terminal  Operators 

Increased  gate  moves/throughput 

Pre -notification  of  truck  arrival 

More  efficient  use  of  labor/equipment 

Enhanced  customer  service 

Reduced  paperwork 

Truck  Drivers 

Reduced  wait  times  at  border  and  port  terminals 

Fuel  savings  from  reductions  in  wait  times 

Increased  capacity  for  additional  moves 

Reduced  paperwork 

Regional  Transportation  Agencies 

Improved  planning  for  freight  transportation 

Increase  in  commercial  vehicle  safety 

U.S.  Customs/U.S.  and  Mexican 
Governments 

Improved  security  through  E-Seal  verification 

Improved  security  through  truck  tracking 

Improved  throughput  of  trucks  at  border  crossing 
Reduced  paperwork 

Customers 

Improved  tracking  and  visibility  of  cargo 

Improved  ability  to  support  just-in-time  logistics 

Lower  costs  (efficiency  improvements) 

Table  1:  Expected  Benefits  of  the  Integrated  Tracking  System 
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3.1  ITS  Initial  Operating  Capability  Deployment  and  Testing 

As  depicted  in  Figure  3,  the  initial  testing  of  the  ITS  and  SM21  Tracking  and  Experimentation 
Database  (data  repository)  will  employ  TCOS  feeding  input  directly  to  the  SM21  Experimental 
Database.  This  initial  testing  environment  will  be  supplemented  by  the  deployment  of  the 
IntelliTrans-TransCore  suite  of  systems. 

In  open  sources  a  significant  number  of  experienced  SOA  developers  have  two  words  of  advice: 
Start  small  or  as  stated  earlier  talk  a  little,  model  a  little,  learn  a  lot.  Incremental  change  and 
gradual  improvements  will  be  employed  rather  than  developing  the  objective  system  without  first 
developing  and  deploying  small  focused  capabilities.  In  the  case  of  the  ITS,  the  first  deployment 
will  integrate  business  and  IT  strategies  to  provide  Dole  with  common  services  that  leverage 
existing  and  limited  new  functionality.  To  achieve  success,  the  ITS  development  will  start  with 
the  TCOS  system  and  the  integration  of  the  Dole  Foods  provided  AMS  data,  a  project  with 
future  business  value.  Throughout  the  first  year  of  capability  deployment,  the  ITS  project  will  be 
tightly  focus  on  continuing  to  evolve  the  Dole  supply  chain  tracking  services.  The  aim  is  to  start 
off  with  a  few  key  SOA  pieces  without  trying  to  initially  develop  the  objective  environment. 
Following  the  initial  data  integration,  the  second  stage  deployment  will  begin,  which  involves 
testing  the  SM21  developed  Experimental  Database  (CLIN0009).  Subsequent  to  a  successful 
test,  the  project  will  begin  the  iterative  talk  a  little,  model  a  little,  learn  a  lot  process  until  the 
Dole  Food  and  SM21  Team  can  declare  “success”. 


3.1.1  Commercial  Off-the-Shelf  System  Integration 

The  ITS  and  IP-MTOPS  systems  will  be  heavily  dependent  on  COTS  and  Government  legacy 
applications,  which  includes  mode  and  terminal  operator  owned  systems  and  SM2 1  partner 
systems,  primarily  those  of  IntelliTrans-TransCore,  CDM  (ICODES  and  TRANSWAY),  and  to  a 
lesser  degree  SAVI-Lockheed  Martin.  The  IntelliTrans-TransCore,  CDM,  and  SAVI  suites  of 
systems  have  been  tested  in  both  commercial  and  government  service  thereby  uniquely  enabling 
SM21  to  accelerate  the  development  of  an  initial  operating  capability  based  in  a  public-private 
partnership  role. 

The  initial  focus  will  be  the  deployment  of  the  TransCore  3sixty  application,  a  complete 
shipment  and  asset  management  operating  system,  which  is  capable  of  supporting  military  and 
commercial  shipments  through  Southern  California.  Using  3sixty  as  the  basic  operating  system, 
SM21will  deploy  the  required  backbone  for  the  development  and  execution  of  a  comprehensive 
experimentation  program  during  the  follow-on  program  effort  starting  in  September  2007. 

The  strategy  for  deploying  3 sixty  is  to  develop  a  well  defined  and  detailed  project  plan  within  the 
first  two  weeks  of  contract  award  that  will  establish  the  deployment  timetable.  The  program  will 
be  managed  by  a  dedicated  IntelliTrans  project  manager.  The  immediate  development  of  the 
project  plan  will  support  the  rapid  deployment  of  the  required  SM21  initial  operating  capability. 
This  initial  capability  deployment  to  support  and  operate  an  Integrated  Tracking  System  will 
employ  existing  COTS  solutions  that  will  require  minimal  development  and  customization. 

Using  3sixty  and  ICODES  for  the  support  backbone,  SM21  will  complete  an  experimentation 
program  that  leverages  coordination  previously  conducted  with  USTRANSCOM  for  a  military 
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force  deployment  demonstration  in  the  Pacific  Northwest,  as  well  as  the  Dole  Foods  commercial 
container  shipment  optimization  studies.  The  SM21  support  efforts  related  to  the  Green  Freight 
Corridor  Network  will  be  greatly  benefited  by  the  early  deployment  of  the  initial  ITS 
capabilities. 

The  experiments  and  Green  Freight  Corridor  Network  development  will  assist  in  the  evaluation 
of  hypotheses,  JDDSP  concept  refinement,  and  achieving  substantive  objectives  established  by 
both  commercial  and  government  entities.  The  effort  will  include  supporting  the  integration  of 
TRANSWAY,  ICODES,  and  AALPS  into  3sixty  and  the  experimentation  plan.  This  will  assist 
SM21  in  the  development  of  the  specifications  for  a  combined  commercial  and  government 
movement  common  operating  picture. 

As  the  basic  operating  capability  for  the  initial  ITS,  3sixty  will  facilitate  experimentation  and 
drive  the  JDDSP  concept  to  an  initial  operating  capability  (IOC).  The  core  premise  for  this 
deployment  is  to  provide  SM21  with  a  flexible  suite  of  products  that  delivers  the  information  and 
services  needed  for  customers  to  make  their  transportation  enterprise  as  efficient  and  profitable 
as  possible.  The  3sixty  suite  of  products  and  services  selected  for  deployment  will  provide  a 
variety  of  operations  management  tools  that  will  be  employed  to  run  the  ITS  and  ultimately  the 
JDDSP. 

These  tools  include: 

•  TCOS  -  Trade  Corridor  Operating  System  -  the  initial  ITS  application  to  be  deployed 

•  Global  Visibility  Platform  -  multi  modal  asset  and  shipment  tracking,  to  include  a  yard 
management  system 

•  An  integrated  service  application  composed  of  six  (6)  core  services: 

•  Freight  Match  Services 

•  Fleet  Management 

•  Operations  Management 

•  Compliance  Services 

•  Financial  Services 

•  Rail-Intermodal  Services  (including  track  and  trace). 

In  addition  to  the  applications  outlined  above,  a  variety  of  technical  solutions  to  support 
experimentation  for  the  JDDSP  will  be  employed.  This  includes  AEI  tags  and  readers  for  the  rail 
and  intermodal  network,  RFID  tags  for  trucks,  trailers  and  containers,  and  GPS  units  for 
ubiquitous  visibility. 

The  following  sections  provide  more  detailed  information  on  the  ITS  initial  system  architecture 
components. 

3.1.2  Trade  Corridor  Operating  System 

This  section  of  the  document  provides  a  description  of  the  fundamental  characteristics  of  Trade 
Corridor  Operations  System  (TCOS)  and  its  applicability  to  the  ITS  and  IP-MTOPS. 
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3. 1.2.1  Background  and  Applicability  to  ITS-Agile  Port  System  Demonstration 

TCOS  is  a  system  of  hardware  and  software  that  was  developed  by  TransCore  originally  for  the 
Washington  State  Department  of  Transportation  (WSDOT)  to  implement  the  Northwest 
International  Trade  Corridor  and  Border  Crossing  System  (NWITC).  The  NWITC  is  an 
operational  secure  freight  management  pilot  program  managed  by  the  WSDOT  Intelligent 
Transportation  Systems  (ITS)  office.  The  ports  of  Seattle  (American  President  Lines  (APL))  and 
Tacoma  (Maersk-Sealand)  are  integrated  into  the  system  along  with  the  Washington  State 
Commercial  Vehicle  Information  Systems  and  Networks  (CVISN)  weigh  stations  and 
commercial  vehicle  database.  These  sites  are  outfitted  with  roadside  Automatic  Vehicle 
Identification  (AVI)  sensors  (to  read  CVISN  Radio  Frequency  Identification  (RFID)  vehicle 
tags)  and  other  RFID  sensors  for  reading  electronic  container  seals  (e-seals)  and  Free  And  Secure 
Trade  (FAST)  compatible  vehicle  sticker  tags  and  driver/crew  ID  cards.  The  US  Department  of 
Homeland  Security  bureau  of  Customs  and  Border  Protection  (DHS  CBP)  commercial  vehicle 
processing  facility  at  Blaine  (at  the  Washington  border  with  Canada)  is  also  instrumented  with 
AVI,  e-seal  and  FAST  RFID  sensors.  This  integrated  secure  freight  management  system 
monitors  the  movement  of  freight  transactions  moving  north  and  south  along  Interstate  5, 
between  Seattle/Tacoma  and  Vancouver,  BC,  Canada. 

The  Pacific  Northwest  TCOS  deployment  will  significantly  reduce  the  risk  of  the  SM21  support 
to  the  PNW  Agile  Port  System  (APS)  force  deployment  demonstration.  While  some  of  the  initial 
ITS  testing  will  be  completed  in  Southern  California,  the  first  near  full  operating  capability  test 
in  an  actual  deployment  will  occur  in  the  PNW.  A  phased  demonstration  build-up  process  will 
be  established  as  part  of  the  APS  demonstration  plan  to  further  mitigate  risk. 

3. 1.2.2  TCOS  Functional  Design  -  Web  Service 

TCOS  includes  both  site  sensor  controller  hardware  and  software,  and  regional  data  center 
hardware  and  software.  The  site  controllers  all  share  a  common  set  of  software  that  is  uniquely 
configured  for  each  site.  The  site  controllers  are  responsible  for  interfacing  with  sensor 
hardware,  buffering  sensor  hardware  status  and  RFID  read  events,  and  reporting  to  the  TCOS 
data  center  (via  a  secure  Internet  connection).  The  data  center  receives  reports  from  all  of  the  site 
controllers  in  near  real  time.  The  reported  status  and  events  are  processed  and  stored  in  a 
database.  The  TCOS  web  server  provides  real  time  access  to  this  information  to  authorized  users 
on  the  Internet  via  a  secure  website  (www.transcorridor.com).  TCOS  also  receives  and 
distributes  event  reports  from  other  sources  such  as  the  seaports  and  weigh  stations  via  their 
respective  information  management  systems  (IMS).  Near  real  time  interfaces  supported  by 
TCOS  include:  email  and  cellular  phone  paging  alerts  to  stakeholders  and  enforcement  agents; 
TCP/IP  Socket,  FTP,  SOAP,  eForward,  and  other  Internet-based  interfaces  with  stakeholder 
IMS;  and  direct  interfaces  to  the  CBP  Automated  Manifest  System  (AMS). 

3. 1.2.3  TCOS  Deployability 

Although  developed  originally  for  NWITC,  TCOS  is  a  flexible  baseline  freight  management 
system  that  can  be  adapted  by  SM21  to  other  regions.  TransCore,  and  SM21  by  extension,  has 
been  granted  permission  by  WSDOT  to  utilize  TCOS  for  such  projects.  TCOS  has  been 
successfully  adapted  for  three  trade  lanes  (two  with  BVSG/TransCore  and  one  with  SAIC/Savi) 
in  the  Operation  Safe  Commerce  (OSC)  project,  and  it  is  being  extended  to  cover  US 
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Department  of  Agriculture  (USD  A)  Agricultural  Inspection  Policy  and  Programs  (AIPP)  trade 
lanes.  TCOS  will  be  configured  by  the  SM21  team  to  include  new  sensor  sites  using  the  existing 
TCOS  data  center  at  TransCore  in  San  Diego,  California.  If  necessary  (for  security  or  other 
reasons),  the  TCOS  data  center  software  can  be  cloned  and  modified  to  support  other  trade  lanes 
and/or  other  freight  management  projects  on  other  server  hardware  and/or  at  other  physical 
locations  for  the  DoD.  The  TCOS-ITS  application  will  include  commercial  vehicle  trucks  along 
with  marine  and  rail  transportation  elements.  The  software  architecture  of  the  SM21  ITS  TCOS 
deployment  (in  the  data  center  and  the  site  controller  components)  will  enable  rapid  development 
and  integration  of  software  drivers  for  interfaces  to  new  sensor  types  and  new  communication 
protocols  for  interfaces  to  other  systems  for  testing,  experimentation  and  deployment. 

3. 1.2.4  TCOS  Adaptability  Considerations 

The  TCOS  software  configuration  within  the  SM21  ITS  will  enable  the  adaptation  of  the  SM21 
products  to  a  variety  of  dual-use  freight  management  system  projects.  The  fundamental 
architecture  provides  a  core  of  common  code  that  will  enable  SM2 1  to  provide  both  basic  and 
industry-specific  features  consistently  for  all  SM21  ITS  application  modules.  This  core  includes 
everything  form  high-resolution  event  timing  to  various  forms  of  communication  to  diagnostic 
logging  to  event  correlation.  Basic  higher-level  TCOS  application  modules  provide  coordinated 
event  logging,  homogenized  external  device  connections,  sensor  and  output  device  drivers,  and 
generic  site  controllers  and  data  center  functions. 

The  SM21-ITS  TCOS  supported  application  modules  communicate  using  a  common  messaging 
interface  via  TCP/IP  (the  low-level  protocol  of  computer  networks  -  including  the  Internet).  This 
TCOS  language  (a  simplified  and  more  flexible  derivative  of  XML)  will  allow  SM21  ITS 
modules  to  be  distributed  in  a  variety  of  ways  using  simple  configuration  file  settings.  Multiple 
modules  will  be  run  on  the  same  computer,  on  different  computers  across  a  local  area  network, 
across  the  world  via  the  Internet,  or  any  combination  without  changing  any  code.  The  SM2 1  ITS 
TCOS  application  will  employ  dynamic  programming  languages  to  enable  modules  to  run  on 
different  computer  operating  systems  without  code  changes.  The  TCOS  language  is  human 
readable  and  it  can  be  extended  to  message  passing  via  slower  interfaces  such  as  email,  website 
forms,  and  interactive  human  text  messaging  sessions. 

The  TCP/IP  connection  protocols  in  the  SM21  ITS-TCOS  application  modules  will  be  made 
more  flexible  by  having  each  module  a  multiple  simultaneous  user  server  as  well  as  a  potential 
client  to  multiple  other  TCOS  modules.  A  primary  design  feature  will  enable  fast  configuration 
of  complex  networks  that  will  also  allow  human  users  to  monitor  the  activities  of  any  SM21  ITS- 
TCOS  application  module  without  disrupting  its  normal  operation  (accelerating  development, 
configuration,  testing,  diagnostics,  and  maintenance). 

The  extensive  use  of  dynamic  languages  will  enable  SM21  to  rapidly  develop  new  features  and 
entire  new  modules  for  the  SM21  ITS-TCOS  as  needed  to  implement  the  requirements  of  the 
ITS  in  other  regions  and  deployment  scenarios.  The  standardization  of  module-to-module 
communications  means  that  such  features  do  not  need  to  be  reengineered,  and  new  connections 
between  modules  are  very  straightforward  (very  little  redesigning  required  to  accommodate  new 
modules  in  the  SM21  ITS-TCOS  network). 
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The  TCOS  communication  language  is  defined  using  object-oriented  configuration  files  that 
serve  to  efficiently  implement  a  great  deal  of  the  TCOS  applications,  as  well  as  simultaneously 
implementing  the  system  interface  documentation  (built  in  to  the  client  interfaces  as  online 
interactive  text,  and  also  accessible  via  a  web  browser  for  dynamic  interactive  navigation).  This 
arrangement  means  that  the  system  interface  documentation  is  never  out  of  synch  with  the  actual 
products  because  both  come  from  exactly  the  same  source. 

3. 1.2.5  SM21 ITS-TCOS  Capabilities 

TCOS  implements  five  (5)  major  functions  that  are  all  applicable  to  multiple  ITS  projects  such 
as  NWITC,  OSC  and  others.  These  are  significant  functions  that  are  not  easily  developed  from 
scratch.  The  SM21  ITS-TCOS  will  be  deployable  stand-alone  as  the  IMS  data  center  for  a 
project,  or  the  design  will  enable  the  interface  with  a  higher-level  IMS.  Higher-level  IMS  do  not 
typically  support  the  lower-level  TCOS  functions,  so  TCOS  bridges  the  gap  between  site  sensors 
and  other  IMS  and  analysis  tools.  Frequently  the  higher-level  systems  and  tools  require  access  to 
proprietary  and  Security  Sensitive  Information  (SSI)  that  needs  to  be  protected.  The  SM21  ITS- 
TCOS  deployments  will  be  able  to  serve  securely,  and  with  low  risk  in  such  environments,  as  a 
gateway  -  by  using  index  values  for  data.  Highly  secured  IMS  can  use  the  index  values  reported 
by  the  SM21  ITS-TCOS  to  reference  the  protected  information.  Using  TCOS  rather  than 
developing  lower-level  interfaces  for  other  IMS  leverages  the  maturity  already  invested  in 
TCOS.  TCOS  first  went  operational  for  NWITC  in  1999  and  has  been  continuously  maintained, 
updated,  and  improved.  The  current  architecture  of  TCOS  has  been  running  continuously  in  the 
NWITC  since  June  of  2002  -  processing  hundreds  of  transactions  per  day.  Dramatically 
enhanced  TCOS  software  has  been  tested  and  will  be  deployed  with  the  SM21  ITS-TCOS  data 
center  hardware. 

3. 1.2.6  Major  Functions  SM21  ITS-TCOS 

1  -  Data  Acquisition: 

The  sensor  site  controller  components  of  the  SM21  ITS-TCOS  will  interface  with  various  RFID 
readers  and  other  sensors  and/or  output  devices  (such  as  driver  signals,  active  barriers  and 
variable  message  signs)  to  monitor  hardware  status  and  to  acquire  events  (such  as  tag  reads). 
These  status  and  event  records  will  be  time  and  date  stamped,  correlated  with  each  other, 
associated  with  the  site,  and  buffered.  Event  records  will  be  reported  in  real  time  or  in  batch  (on 
a  periodic/timed  schedule)  to  the  SM21  ITS-TCOS  central  data  center,  local  IMS,  and/or  to  a 
SM21  ITS-TCOS  regional  data  center.  The  site  controller  will  also  be  configured  as  a  server  so  a 
data  center  can  actively  retrieve  buffered  data  from  the  site  instead  of  having  the  site  actively 
send  data  to  the  data  center.  The  default  will  be  for  the  sites  to  actively  connect  to  the  SM21  ITS- 
TCOS  central  data  center  and  send  event  data  and  hardware  status  changes  in  real  time  (as  soon 
as  it  is  detected).  A  separate  configuration  option  will  have  the  site  report  its  current  status 
periodically  -  so  the  data  center  will  know  that  the  site  is  still  functioning  -  even  if  it  has  nothing 
new  to  report.  For  data  redundancy  and  system  diagnostics,  site  controllers  will  also  be 
configured  to  log  events,  status,  and  other  site  activity  to  local  hard  drives. 

2  -  Data  Collection 

The  first  function  of  a  SM21  ITS-TCOS  data  center  will  be  to  collect  the  status  and  event  reports 
from  all  of  the  sensor  site  controllers  and  record  them  in  a  central  database.  The  application  will 
collect  this  kind  of  data  from  other  external  sources  (such  as  other  IMS  described  in  this 
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document)  when  the  sensors  are  not  integral  components  of  TCOS.  This  data  can  be  received  in 
real  time  or  in  batch.  The  site  controllers  will  feature  buffering,  to  allow  the  SM21 ITS-TCOS 
data  center  to  go  down  for  extended  periods  of  time  without  losing  status  and  event  data.  Since 
the  site  controllers  will  all  time  and  date  stamp  all  records,  batch  reports  will  still  be  put  into  the 
database  correctly.  The  SM21  ITS-TCOS  will  receive  data  from  handheld  readers  when  docked 
to  an  Internet-connected  computer,  or  event  data  will  be  entered  manually  into  the  SM21  ITS- 
TCOS  via  either  email  or  a  website  form. 

3  -  Regional  Data  Sources 

Extensive  research  was  conducted  on  the  sources  of  regional  tracking  data  outside  of  customer 
and  transportation  mode  and  terminal  operators.  The  regional  tracking  area  is  defined  by  the 
geographic  area  of  responsibility  for  SCAG  as  overviewed  in  Figure  1.  Throughout  the  region 
significant  investment  in  ITS  technologies  has  been  and  continues  to  be  used  to  help  increase  the 
efficient  management  of  the  transportation  networks.  ITS  applications  provide  the  region  with 
key  management  tools  that  help  the  operational  efficiency  of  the  transportation  network.  ITS 
applications  also  contribute  to  security  and  safety.  The  greatest  challenges  and  perhaps  the 
greatest  benefits  lie  in  integrating  major  systems  across  the  entire  region.  The  SM21-ITS  will 
help  to  overcome  some  of  the  challenges  and  provide  the  region  will  additional  value  add  for  its 
investment  in  sensor  and  ITS  technology.  The  recently  documented  Southern  California 
Regional  ITS  Architecture  document  is  a  primary  reference  for  the  sources  of  ITS  event  data 
within  the  region.8  Currently  the  region’s  freeway  networks  are  equipped  with  the  following: 

•  Vehicle  Detection  Stations  (VDS), 

•  Closed-Circuit  Television  (CCTV)  cameras, 

•  Changeable  Message  Signs  (CMS), 

•  Ramp  Meter  Stations  (RMS), 

•  Highway  Advisory  Radio  (HAR),  and 

•  Environmental  Sensor  Stations  (also  known  as  road  weather  information  systems 
(RWIS)) 

The  ITS  field  elements  are  connected  to  the  Regional  Caltrans  Transportation  Management 
Centers  (TMCs)  depicted  in  Figure  5  below. 


8  Southern  California  Regional  ITS  Architecture,  NET,  Final  Version  6.0,  April  2005 
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Figure  6:  Caltrans  TMC  Interfaces  ITS  Data  Flows 


The  Freeway  Performance  Measurement  System  (PeMS)  included  in  Figure  5  is  a  consolidated 
database  of  information  collected  via  Caltrans  loop  detectors  and  provided  as  a  Web  Service  by 
Caltrans  through  the  University  of  California,  Berkley.  The  intent  is  to  work  with  SCAG  and 
Caltrans  to  integrate  selected  ITS  data  flows  defined  in  Figure  5  with  the  SM21  ITS. 


4  -  Data  Processing 

The  SM21  ITS-TCOS  will  be  able  to  both  store  raw  site  status  and  event  records  and  apply 
logical  processing  to  the  data.  The  system  will  be  capable  of  automatically  evaluating  status  and 
event  reports  to  check  for  security  status,  route  compliance,  travel  time  compliance,  geographical 
boundary  compliance  (geo-fencing),  authorized  transaction  component  correlation  consistency, 
credentials,  and  membership  in  targeting  lists. 


9  Southern  California  Regional  ITS  Architecture,  NET,  Final  Version  6.0,  April  2005 
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When  events  are  reported  from  multiple  sensors  at  the  same  site,  those  records  are  often  related 
to  each  other  and  will  need  to  be  combined  into  a  singe  composite  event.  This  correlation  can  be 
done  in  the  site  controller,  but  the  SM21  ITS-TCOS  will  the  correlation  to  be  completed  in  the 
SM21  ITS-TCOS  data  center  so  that  the  code  can  be  managed  in  a  single  place.  When  events 
reported  by  different  sites  and/or  other  IMS  require  correlation,  the  correlation  function  will  be 
performed  by  the  SM21  ITS-TCOS  data  center. 

Another  form  of  correlation  that  the  SM21  ITS-TCOS  will  perform  is  the  evaluation  of  event 
data  relative  to  prior  detections  of  the  same  transaction  item.  This  will  include  measuring  travel 
time  between  sites  and  comparing  that  to  allowable  tolerances.  This  also  involves  monitoring 
where  transaction  components  change  associations  (seal-to-container,  container-to  vehicle, 
driver-to- vehicle,  etc.),  and/or  security  status  (sealed  or  tampered).  Travel  time  checks  between 
gateways  in  a  trade  lane  rout  are  a  critical  component  in  building  a  secure  freight  management 
system. 

The  SM21  ITS-TCOS  will  also  check  event  data  against  credential  criteria  and  targeting  lists 
(specified  by  authorized  agents)  to  generate  alerts.  Another  data  collection  capability  of  the 
SM21  ITS-TCOS  will  be  the  retrieval  and/or  receipt  from  other  IMS:  enrolments,  registrations, 
credentials,  filings,  and  other  such  information  that  may  be  needed  to  make  these  data  processing 
decisions. 

5  -  Data  Distribution 

The  SM21  ITS-TCOS  will  distribute  its  database  information  in  various  forms  to  multiple 
authorized  recipients.  Authorized  human  users  will  access  real  time  system  status  and  event  data 
tailored  for  them  using  the  SM21  ITS-TCOS  web  portal.  Targeting  will  be  set  to  generate  alert 
reports  via  email  to  other  IMS  or  to  authorized  human  agents  (via  email  or  cellular  phone  text 
paging/messaging)  when  certain  types  of  events  occur.  Other  Internet-based  protocols  can  be 
used  to  exchange  data  with  other  IMS.  As  required,  non  Internet-based  communication  channels 
will  be  used  (such  as  the  TCOS  to  DHS  CBP  AMS  interface).  New  protocols  will  be  adapted  to 
the  SM21 1  ITS-TCOS  to  interface  with  new  IMS,  or  a  standard  protocol  that  TCOS  already 
supports  can  be  selected  (such  as  EDI  or  XML). 

6  -  System  Maintenance 

An  SM21  ITS-TCOS  priority  will  be  system  maintenance  functions.  First,  all  sensor  sites  will 
report  their  hardware  status  to  the  data  center  whenever  their  status  changes  -and  periodically. 
Therefore,  the  data  center  database  will  maintain  a  log  of  the  history  as  well  as  the  current  status 
of  all  sensor  site  hardware.  This  information  will  be  available  on  the  SM21  ITS-TCOS  website  to 
all  authorized  users.  The  system  database  will  also  monitor  when  it  has  not  heard  from  a  site  in 
its  expected  reporting  period  and  will  mark  the  site  as  reporting  late  (a  probable  sign  of  trouble). 
The  SM21  ITS-TCOS  database  will  also  mark  all  other  data  sources  (such  as  external  IMS)  if 
they  do  not  communicate  within  a  configurable  time  period. 

Monitoring  site  status  is  not  sufficient  to  support  maintenance  and  the  SM2 1  required  level  of 
service  for  government  services,  especially  when  the  sensor  sites  are  far  away  from  service 
technicians.  The  SM21  ITS-TCOS  sensor  site  controllers  will  all  support  optional  dial-in  auto¬ 
answer  telephone  modems  for  direct  secure  access  to  the  operating  systems  (telnet  and  ftp).  In 
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addition,  the  SM21  ITS-TCOS  site  to  data  center  connection  through  the  Internet  will  support  a 
protocol  that  will  allow  a  maintenance  user  to  access  the  site  system  via  a  mutual  connection  to 
the  data  center  (secure  tunneling). 

The  SM21  ITS-TCOS  applications  will  all  be  designed  to  allow  direct  monitoring  by 
maintenance  users.  This  means  that  a  technician  or  programmer  will  be  able  to  log  on  to  any 
software  component  of  TCOS  and  observe  what  is  going  on  inside  without  disturbing  its  normal 
operation.  This  feature  will  flow  as  far  down  as  the  serial  port  interface  level,  to  enable  a 
maintenance  person  to  diagnose  problems  down  to  the  raw  device  interface.  All  of  this  will  be 
done  remotely  from  anywhere  in  the  world  via  the  Internet  or  direct-dial  connection.  This  makes 
the  basic  assumption  that  either  the  Internet  or  the  modem  connection  is  available  and  working. 
However,  the  inherent  maintenance  features  of  the  SM21  ITS-TCOS  will  save  time  and  travel  in 
most  cases.  In  other  cases,  the  SM21  ITS-TCOS  remote  maintenance  capabilities  will  allow  an 
engineer  to  guide  a  local  technician  to  fix  problems  using  a  voice  telephone  and  an  Internet 
and/or  direct  dial-up  connection. 

3.1.3  SM21  Global  Visibility  Platform  Deployment 

To  take  advantage  of  the  SM21  ITS-TCOS  data,  a  wide  array  of  software  tools  will  be 
incorporated  (including  the  IntelliTrans’  developed  Global  Visibility  Platform,  or  GVP),  which 
will  be  deployed  as  modules.  The  following  are  the  modules  to  be  deployed  within  the  follow- 
on  program  year: 

•  Multi-Modal  In-Transit  Visibility,  and  Intervention  Services:  These  services  include  a 
collection  of  software  tools  built  around  a  Multi-Modal  Tracking  System  (MMTS)  module 
for  tracking  and  tracing  shipments  regardless  of  mode.  The  MMTS  tracking  modules  will 
include: 

•  Rail. 

•  Truck. 

•  Ocean  Vessel. 

•  Intermodal. 

•  Barge. 

•  Rail/Intermodal  RFID  Solutions:  This  includes  RFID  solutions  to  the  bulk  distribution 
network,  including  reads  from  railcar  AEI  tags,  and  the  integration  of  other  RFID  tags. 

•  Telematics:  The  system  will  be  capable  of  providing  telematics  services  through  the 
appropriate  deployment  of  the  TransCore  GlobalWave®  and  other  appropriate  solutions. 

This  type  of  deployment  will  tie  GPS  and  sensor  data  transmission  into  a  single  point  of 
contact  for  hardware,  software  and  services,  enabling  improved  visibility  including: 

•  Load/empty  detection. 

•  Detection  of  valve,  hatch,  or  dome  conditions  (open  or  closed). 

•  Measurement  of  pressure,  temperature,  or  other  continuous  parameters  in  real  time 
and  the  generation  of  alarms. 
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•  Rail  Yard  Management  with  RFID  Solutions:  The  yard  management  module  will  provide  a 
complete  solution  that  is  capable  of  providing  visibility  and  command  and  control  to  multiple 
rail  yards  on  a  global  basis.  By  integrating  a  combination  of  fixed  and  handheld  AEI  Tag 
Readers  as  well  as  human  input,  SM21  will  be  able  to  create  an  efficient  yard  management 
solution  to  support  the  workflow  of  rail  yards. 

Some  of  the  system  functions  will  include  the  generation  of: 

•  Event  Reports. 

•  Switch  Lists. 

•  Digital  Interactive  Maps. 

•  Detention  with  user  defined  rules. 

•  Track  Lists. 

•  Yard  Summary  Report. 

•  Tank  Car  Loader  with  Outage  Tables. 

•  Complex  back  end  logic  to  control  user  actions  based  on  circumstances. 

•  Audit  capability. 

•  Fleet  Management  Module  for  administering  the  maintenance,  lease  and  contractual  aspects 
of  SM21  supported  railcar  fleets.  This  module  will  provide  users  date-range  based  search 
capabilities  on  rail  assets  including: 

•  HM201  tests. 

•  Tank  tests. 

•  Air  brake  tests. 

•  Coil  tests. 

•  Rule  88b  tests. 

•  Out  of  service. 

•  Requiring  repairs. 

•  Empty  Car  Management  Module:  The  Empty  Car  Management  module  will  provide  an 
empty  &  loaded  railcar  visibility  tool  coupled  with  a  diversion  decision  support  system  and  a 
railcar  demand  forecast  system  specifically  designed  to  allocate  railcars  and  will  be  designed 
to  promote  network  optimization. 

•  Global  Vendor  Managed  Inventory  (“GVMI”)  Module  for  enabling  optimal  mode  selection 
and  will  be  designed  to  reduce  working  capital.  The  GVMI  module  will  employ  sensor  and 
telemetry  equipment  to  obtain  and  broadcast  fixed-asset  inventory  levels.  SM21  will  work 
with  RFID  suppliers  to  provide  Vendor  Managed  Inventory  (VMI)  capability  on  packaged 
goods,  such  as  totes,  cylinders  and  pallets. 
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•  BEAM™  Metrics  &  Key  Performance  Indicator  (“KPI”)  Module  for  will  be  deployed  by 
SM21  to  analyze  distribution  chain  performance  and  will  be  capable  of  creating  dashboards 
for  monitoring  distribution  chain  performance.  The  application  will  support  the  build  of 
pivot  tables  and  graphical  metrics  to  support  the  improvement  of  service  level  and  cost 
reduction.  The  KPI  module  will  be  linked  to  an  email  engine  the  will  “push”  KPIs  to  users 
on  a  scheduled  basis. 

•  A  Bill  of  Lading  (BOL)  Generator  Module  will  be  integrated  into  the  shipment  management 
platform  and  connected  via  EDI  to  all  major  railroads  providing  a  common  BOL  platform 
regardless  of  carrier.  Users  will  be  able  to  build  BOL  templates  based  upon  consignee, 
carrier,  commodity,  and  equipment  type  allowing  for  custom  formats  in  an  efficient, 
automated  environment. 

•  Detention  &  Demurrage  Management  Module:  This  module  will  enable  the  management 
of  all  aspects  of  the  railcar  detention  and  demurrage  process  to  reduce  costs,  and  verify  the 
accuracy  of  demurrage  invoices  and  determine  the  potential  dollars  that  might  be  anticipated 
as  detention  revenue  based  on  both  current  and  historical  shipment  information. 

•  Rateables  and  Payables  Module:  The  SM21  GVP  deployed  platform  will  offer  users  the 
ability  to  store  rate  and  route  information  for  all  modes.  A  freight  payables  module  will  be 
built  on  top  the  SM21  database  and  will  match  the  rate  data  to  shipments  and  will  have  the 
capability  to  authorize  and  track  payment  information. 

•  Switch  Performance  Reporting:  The  Switch  Performance  Module  will  monitor  railroad 
performance  and  ensure  railroads  are  fulfilling  their  switch  obligations  at  specific  locations. 

•  Materials  Management  System  (“M2S”):  This  module  will  enable  the  management  of 
operations  controlling  bulk  inventory  transload  facilities. 

SM21  will  also  employ  a  combined  suite  of  transportation  management  services  and  solutions 

under  the  umbrella  of  the  TransCore  3sixty  Transportation  Management  Services,  which  includes 

the  Global  Visibility  Platform  (GVP).  In  addition  to  the  services  listed  above,  the  SM21  3sixty 

deployment  will  also  include: 

•  Freight  Matching  Services:  This  service  will  enable  users  to  ensure  their  loads  are  covered 
by  extending  connectivity  to  the  18,000  brokers  and  carriers  that  utilize  this  service. 

•  Fleet  Compliance  Services:  This  will  include  the  management  of  fuel  tax  reporting,  titling 
and  equipment  compliance,  and  tools  to  help  users  stay  current  on  the  latest  U.S.  Customs 
and  Border  Protection  Regulations,  including  the  Automated  Commercial  Environment 
(ACE). 

•  Wireless  Fleet  Management  Services:  The  deployment  of  this  capability  will  range  from 
RFID-based  systems  for  freight  terminal  gate  access  control  to  state-of-the-art  GPS 
communications  enabling  better  oversight  of  equipment  location  and  status. 

•  Operations  Management  Services:  The  deployment  will  combine  the  services  of  two 
modules  providing  brokerage  management  solutions,  including  order  management,  accounts 
receivable,  accounts  payable,  analysis  reports,  general  ledger  interfacing,  and  EDI  data 
transmission  with  rating,  tendering,  scheduling,  and  in-transit  visibility  of  shipments. 
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•  Financial  Management  Services:  This  module  includes  fuel  cost  management,  factoring, 
credit  reporting,  rate  indexing,  and  assurance  services. 

3.2  Future  ITS  Development  and  Integration  with  IP-MTOPS 

The  integrated  systems  will  be  tested,  redesigned  or  replaced  as  appropriate  by  more  effective 
modules  to  support  the  designed  stepwise  (incrementally)  deployment  of  a  Service  Oriented 
Architecture  based  Inland  Port  Multi-Modal  Terminal  Operating  System  (IP-MTOPS)10.  The 
IP-MTOPS  requirements  are  documented  in  an  SM21  developed  specification.  As  noted  in  the 
specification,  no  one  single  commercial  software  system  will  meet  all  the  technical  and 
functional  requirements  defined  in  the  specification.  Some  or  all  of  the  systems  tested  as  part  of 
the  IOC  testing  of  the  SM21  ITS  will  be  deployed  within  the  IP-MTOPS  environment.  Other 
systems  and  services  will  be  procured  and  implemented  by  the  individual  tenants  such  as  air 
cargo  and  intermodal  rail  terminal  operators.  However,  as  required,  SM21  will  also  support  the 
selection,  or  limited  development,  of  systems  capable  of  filling  identified  military  and 
commercial  support  gaps  and  to: 

•  Enable  efficient  terminal  operations  in  support  of  commercial  and  military  shipments  by 
optimizing  logistics  flows, 

•  Help  maintain  desired  individual  terminal  and  collective  inland  port  productivity 

•  Maintain  high  customer  service  quality, 

•  Strengthen  customer  relationships  through  up  to  the  minute  visibility  of  shipments  and 
quick  shipment  processing  times. 

The  future  development  of  the  ITS  and  integration  with  the  IP-MTOPS  is  overviewed  in  Section 
5.0. 


10  The  Inland  Port  Management  Information  System  (IP-MTOPS)  will  be  developed  by  the  Strategic  Mobility  2 1 
program  to  support  the  Southern  California  Logistics  Airport  (SCLA)  and  the  Joint  Power  Projection  Platform  as 
defined  within  this  document  and  supporting  SM21  documentation. 
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4.0  Integrated  Tracking  System  Testing  and  Experimentation 

As  the  capabilities  are  deployed  and  tested,  appropriate  experimentation  will  begin.  The 
deployment  of  capabilities  required  to  conduct  the  Dole  Food  supply  chain  studies  and  APS 
PNW  force  deployment  demonstration  will  be  deployed  and  tested  first.  Several  smaller  tests  of 
the  required  integrated  modules  will  be  conducted  in  both  Southern  California  and  in  the  PNW. 

The  complete  deployment  process  and  experimentation  plan  will  be  documented  in  a  project 
management  plan  to  be  completed  within  the  first  two  weeks  of  the  follow-on  program  year  after 
all  appropriate  team  member  contracts  are  in  place. 


4.1  SM21  Tracking  Experimentation  Database 

As  an  early  objective,  the  SM21  Tracking  Experimentation  Database,  as  depicted  in  Figure  3, 
will  undergo  initial  operational  testing  before  deployment  to  a  beta  production  environment.  The 
database  has  been  incrementally  developed  over  several  years  and  during  the  current  project 
period  of  performance  as  CLIN0009. 

The  JDDSP  requires  an  ITS  that  is  based  on  integrated  data  standards  and  standard 
communication  protocols.  The  ITS  must  have  the  ability  to  support  improved  goods  movement 
and  provide  effective  decision  support  for  full  spectrum  military  surge  deployment,  sustainment, 
redeployment,  and  reset  operations.  The  JDDSP  conceptual  system  architecture  will  be 
composed  of  layers  including:  a  data  capture  and  integration  layer;  a  mediation  layer;  and  an 
information  interfacing  layer  to  perform  Extraction,  Transformation,  and  Loading  (ETL) 
processes.  The  ETL  processes  allow  the  raw  data  to  be  converted  to  useful  information  for  both 
commercial  and  military  shipment  management. 

Accordingly,  using  data  and  data  flows  to  represent  the  physical  movement  and  key  control 
elements  in  the  shipment  tracking  system,  we  seek  to  define  the  Information  Technology  (IT) 
architecture  required  to  capture  the  major  attributes  and  associated  data  elements  in  the  area  of 
shipment  tracking.  Tracking  data  required  by  the  JDDSP  includes  commercial  and  military 
Electronic  Data  Interchange  (EDI)  segments;  Car  Location  Messages  (CLM);  Auto  Equipment 
Identification  (AEI)  technology;  Radio  Frequency  Identification  (RFID)  tags;  and  sensor  readers 
to  track  containers  and  equipment  moving  to  and  through  the  JDDSP. 

The  development  of  the  JDDSP-ITS  will  start  with  building  an  integrated  database,  configuring 
secure  data  capture  and  integration  networks,  creating  the  information  interfacing  layer  and 
ending  with  a  web  demonstration  through  the  IP-MTOPS  Web  Portal. 

4.2  Joint  Data  Standards,  Communication  Protocol,  and  Database  Objectives 

To  develop  joint  data  standards  and  communication  protocols  in  the  ITS,  we  set  the  following 
objectives  to  focus  development  and  ultimately  support  stakeholders.  The  objectives  will  be 
used  as  a  start  point  for  the  development  of  the  ITS  test  plan: 

■  A  collaborative  community  of  interest  comprised  of  military  and  commercial  logistics 
planning  managers  (i.e.,  shipper  activity  planners,  rail  planners,  truck  planners, 
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intermediate  node  planners,  marine  terminal  planners,  vessel  load  planners,  and  end 
users); 

■  An  automated  and  secure  data  center  with  multi-tier  networks,  server  process,  domain 
name  controller,  firewall  routers,  SQL/Oracle  databases,  backup/recovery  plans,  and 
various  ETL  programs; 

■  A  strategic  and  operational  logistics  data  standards  and  communication  protocol 
which  can  be  used  to  track  vessel  manifest,  rail  waybill,  throughput  velocity, 
equipment  security,  and  shipping  synchronicity  of  container  and  military  equipment 
movement;  and 

■  All  shippers  and  regional  Distribution  Centers  to  have  instant  visibility  of  container 
and  equipment  shipments  which  can  enable  timely  supply  chain  distribution  and  force 
deployment  decisions  using  XML  internet  from  everywhere  in  the  world. 

4.3  ITS  Test  Plan  Development 

An  initial  task  during  the  follow-on  period  of  performance  will  be  the  development  of  the  ITS 
test  plan  based  on  the  integration  of  the  Dole  Foods  AMS  EDI  data,  TCOS,  the  SM21  Tracking 
Experimentation  Database,  using  the  beta  IP-MTOPS  web  interface. 
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5.0  Inland  Port  Multi-Modal  Terminal  Operating  System  (IP-MTOPS) 

The  Inland  Port  Multi-Modal  Terminal  Operating  System  (IP-MTOPS)  will  manage  the 
exchange  of  structured  and  unstructured  data  provided  by  the  SM21  ITS-  and  other  freight  and 
asset  management  software  systems  employed  for  moving  freight  into,  out  of,  and  within  the 
SCLA.  Collectively  these  external  and  internal  facility/information  systems  will  provide  the 
information  necessary  for  the  IP-MTOPS  to  perform  the  manipulation,  temporary  storage, 
retrieval,  transmission  and  presentation  of  actionable  information.  The  primary  IP-MTOPS 
function  will  be  to  provide  timely,  actionable  data  needed  by  decision  makers  to  manage 
terminal  and  inland  port  operations  associated  with  the  JDDSP  and  SCLA.  This  will  be 
accomplished  through  electronically  generated  information  reports  that  are  integrated  from  the 
data  provided  by  the  SM2 1  ITS  and  the  various  operating  systems  within  the  SCLA  and  other 
systems  that  support  freight  movement  through  the  SCLA.  This  information  will  be  made 
available  through  the  IP-MTOPS  Web  portal. 

The  IP-MTOPS  will  be  used  for  the  dissemination  of  actionable  information  to  individual 
terminal  personnel  and  for  automating  information  collection,  consolidation,  and  analysis  efforts 
at  the  terminal  and  provided  to  internal  and  external  SCLA- JDDSP  customers.  IP-MTOPS  will 
be  deployed  using  a  network  service  oriented  architecture  designed  to  share  information 
worldwide  via  Internet  or  private  virtual  networks.  The  IP-MTOPS  Architecture  will  support  the 
stepwise  employment  of  XML  and  Web  Service  technologies  designed  to  specifically  support 
the  SCLA- JDDSP  Business  Community  of  users. 

The  IP-MTOPS  will  be  focused  on  supporting  the  functional  management  associated  with 
controlling  the  inland  port’s  (SCLA)  physical  operational  flow  of  transportation  assets,  cargo  and 
personnel.  The  IP-MTOPS  must  be  capable  of  supporting  the  requirements  of  both  military  and 
commercial  shippers.  The  system  will  not  only  support  the  throughput  of  shipments  via  a  single 
mode  but  must  also  support  modal  diversions  and  shipment  trans-loading  operations  for  both 
import  and  export  shipments. 

5.1  Application  Development  Scenario 

The  application  will  be  develop  using  a  planned  approach  of  incrementally  introducing  SM21 
team  members  and  other  SCLA- JDDSP  stakeholders  to  Web  Services.  SM21  could,  acting  on 
behalf  of  the  SCLA  local  authority,  establish  the  neutral,  not-for-profit  entity  needed  to  establish 
and  maintain  a  Private  Universal  Description,  Discovery,  and  Integration  (UDDI)  Registry1 1  for  the 
SCLA- JDDSP  Business  Community  (or  Logistics  Community  of  Practice  (LCOP)).  Further,  SM21 
will  support  the  development  of  a  secure  environment  to  ensure  secure  document  and  data 
interchange.  Figure  7  below,  the  SM21  OV  IB,  provides  an  operational  overview  of  the  SCLA- 
JDDSP  Business  Community  Service  Infrastructure  which  creates  the  IP-MTOPS. 


11  The  UDDI  specification,  currently  maintained  by  OASIS,  is  not  a  specification  for  describing  Web  services  - 
UDDI  is  simply  used  as  the  yellow  pages  of  Web  services. 


25 


Integrated  Tracking  System  Analysis  &  Concept  Design 


'□1  1 

I  □ 

SM21  Operational  View  IB 


1 .  Publish  standard  service  specifications 


Standardized  Support 
Application  Support:  Plug-ins 


SCLA 

Certification 
Authority  (CA) 


3.  Issues  certificate  to  Provider 


SM21 

Business  Community 
Registry 
(UDDI) 


/  _f 

4.  Search  service;  search  Provider 
Get  Provider’s  certificate 


SM21  Business  Community 
Authority 

2.  Apply  for  registration 
Get  certificate  from  CA 


IP-MTOPS 


5.  SCLA-JDDSP  data  exchange;  access  to  Web 
Services;  exchange  of  signed  and  secured 
documents. 


Business  Community 
Operator 


Data  exchange  over  secured  channel 
(HTTPS/SMTPS) 


Of  V 
Military  Community 
Operator 


ITS-TCOS 


Regional  Tracking  Data  Input 
Through  TCOS  to  JDDSP 


Figure  7:  SM21  OV-1B  -  JDDSP  Business  Community  Service  Infrastructure 


The  initial  use  of  the  requirements  defined  in  this  specification  will  be  to  work  with  SCLA  to 
identify  the  current  and  future  facility  tenant  activities  and  map  their  intended  operating  systems 
against  the  requirements  in  this  document  and  those  established  by  the  SM21  and  SCLA 
enterprise  architectures.  The  focus  of  this  will  be  to  begin  planning  both  the  “on-boarding”  of 
the  tenants’  information  systems  (data  integration  with  the  IP-MTOPS  and  ultimately  registration 
in  the  UDDI).  Capability  gaps  will  identified  by  matching  the  capabilities  proposed  within  this 
document  against  the  tenant  capabilities.  The  gaps  will  be  filled  with  the  acquisition  of 
additional  commercial  off-the-shelf  software  systems  or  through  the  development  of  Web 
services. 


The  IP-MTOPS  application  development  is  centered  on  interfaces  that  enable  collaboration  and 
the  exploitation  of  structured  and  unstructured  data  by  techniques  such  as  data  mining.  As  noted 
above,  commercial  off-the-shelf  software  such  as  intermodal  operating  systems  and  to  some 
extent  multi-modal  operating  systems  already  provide  the  capabilities  to  produce  status 
interfaces  and  to  manage  the  workflow  at  supported  facilities.  The  IP-MTOPS  will  not  duplicate 
the  interfaces  found  in  these  commercial  products.  Instead,  through  the  use  of  this  specification 
and  other  SM21  requirement  development  work,  the  IP-MTOPS  development  will  focus  on 
identifying  and  filling  requirement  gaps. 
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As  an  example,  SM2 1  identified  a  military  capability  gap  between  ship  stow  planning,  ship  load 
sequencing,  and  rail  car  load  and  movement  planning  for  force  deployments.  Planning  a  surge 
deployment  to  minimize  the  impact  on  port  operations,  while  decreasing  deployment  timelines, 
creates  the  requirement  to  sequence  the  arrival  of  rail  cars  so  that  equipment  is  delivered  to  a 
strategic  port  in  the  correct  ship  (deck  and  hold)  loading  sequence.  One  known  gap  is  that  there 
is  no  mechanism  today  to  determine  the  order  that  equipment  will  be  needed  at  the  port  to  put  it 
on  to  a  ship  to  achieve  a  particular  stow  plan.  This  is  done  manually  and  in  real  time  today, 
selecting  equipment  from  the  set  of  equipment  available  at  the  port.  Today  this  often  means 
moving  the  entire  unit  equipment  set  to  the  port  and  then  loading  potentially  one  piece  at  a  time 
instead  of  loading  the  maximum  number  of  decks  and  holds  concurrently  through  all  available 
ship  entry  points.  There  are  other  even  more  significant  issues  surrounding  coordination  with 
Class  I  railroads  but  at  this  point  it  is  sufficient  to  say  that  the  SCLA-JDDSP  will  be  able  to 
develop  Web  services  to  bridge  this  significant  capability  gap. 
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6.0  Integration  Requirements 

The  integration  of  both  military  and  commercial  systems  is  critical  to  the  operation  of  the  IP- 
MTOPS.  The  Figure  8  below  provides  a  representation  of  the  military  systems  requiring 
integration  with  the  overall  IP-MTOPS  system.  The  System  View  1  (SV-1)  for  military  systems 
integration  will  also  be  supported  by  the  commercial  S  V 1 ,  which  will  evolve  more  gradually 
over  time.  The  initial  commercial  SV-1  will  be  developed  at  the  beginning  of  the  follow-on 
period  of  performance  for  the  SM21  program. 


SM21  Military  Support  Functionality  and  Tentative  Interfaces 
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Figure  8:  System  View  1  -  Military  Interface  Requirements 


The  specific  military  and  commercial  integration  requirements  are  provided  in  the  IP-MTOPS 
specification.  It  is  however,  important  to  note  that  the  initial  operating  capability  of  the  SM21 
ITS  must  provide  the  ability  to  produce  and  consume  transportation  standard  ANSI  EDIxl2 
transaction  sets  in  traditional  flat-file  and  corresponding  XML  formats,  including  but  not  limited 
to: 


104  Air  Shipment  Information 
160  Transportation  AEI 
204  Motor  Carrier  Load  Tender 
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110  Air  Freight  Details 

163  Motor  Appointment  Schedule 

214  Motor  Carrier  Shipment  Status 
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216  Motor  Carrier  Shipment  Pick-Up  Notification 

301  Ocean  Confirmation 

309  Customs  Manifest 

315  Ocean  Status 

322  Terminal  Operations  Activity 

324  Vessel  Stow  Plan 

404  Rail  Shipment  Information 

417  Rail  Waybill  Interchange 

423  Rail  Switch  List 

810  Invoice 

824  Application  Advice 
858  Shipment  Information 
944  Warehouse  Receipt  Advice 
996  File  Transfer 


217  Motor  Carrier  Loading  Guide 

304  Ocean  Shipping  Instructions 

310  Ocean  Freight  Receipt 

317  Delivery/Pick-Up  Order 

323  Vessel  Schedule 

350  Customs  Status 

410  Rail  Freight  Details 

418  Rail  Consist 

440  Shipment  Weights 

820  Payment  Order  Advice 

856  Shipment  Notice 

943  Warehouse  Shipment  Advice 

947  Warehouse  Inventory  Adjustment 

997  Functional  Acknowledgement 


The  following  system  information  scenarios  are  provided  as  reference  for  the  development  of  the 
SM21  ITS  initial  deployment  and  testing. 

6.1  Ocean  Import 

•  The  Port  and  Terminal  are  pre-noticed  of  arriving  inbound  cargo  via  the  vessel  manifest. 
U.S.  Customs  provides  Custom  clearance  status. 

Transaction  sets: 

o  Booking  Information,  EDI  301; 
o  Vessel  Manifest,  EDI  309; 
o  Bill  of  Lading,  EDI  304; 
o  Forwarding  Instructions,  EDI  304; 
o  Customs  Clearance  Status,  EDI  350; 
o  Vessel  Stowage  Plan,  EDI  324. 

•  The  Port  provides  status  updates  as  cargo  is  landed. 

Transaction  sets: 

o  Status  Information  EDI  304. 

•  For  efficient  handling  (ramp,  de-ramping)  the  Port  unitizes/containerizes  break-bulk 
cargo  to  suitable  equipment. 

•  Automatic  matching  of  arriving  equipment  and  pre-advised  information  and  system 
suggests  terminal  yard  parking  after  equipment  is  identified  based  on: 

o  Non-matching  equipment  marked  for  quarantined/  investigation; 
o  Customs  Hold/Release  status; 

o  Special  Handling  considerations  (refrigerated,  HAZMAT,  etc.); 
o  Pre-advised  forwarding  instructions; 
o  Foreign  Trade  Zone  (FTZ)  Customs  status. 

Transaction  sets: 

o  Terminal  Operations  Activity  EDI  322. 
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6.2  Ocean  Export 

•  Before  the  cargo  can  be  accepted  the  shipment  details  is  arranged  between  the  exporting 
ocean  carrier  and  shipper. 

Transaction  sets: 

o  Booking  Information,  EDI  301; 
o  Bill  of  Lading,  EDI  304; 
o  Forwarding  Instructions,  EDI  304; 
o  Customs  Clearance  Status,  EDI  350; 
o  Vessel  Stowage  Plan,  EDI  324. 

•  Based  on  stowage  plans,  booking  information  and  local  yard  situation,  the  Port  plans  the 
train  loading  sequence  and  sends  that  to  the  Terminal. 

•  Terminal  system  verify  load  ordering  against: 

o  Equipment  and  pre-advised  information; 
o  Customs  hold/release  status; 

o  Special  Handling  considerations  (refrigerated,  HAZMAT,  etc.). 

•  Terminal  loads  the  train  according  to  port  ordering. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

6.3  Highway  Arrival 

•  The  Terminal  is  receives  shipment  information  from  the  Consignor. 

Transaction  sets: 

o  Load  Tender,  EDI  204; 
o  Transportation  Status,  EDI  214. 

•  Trucker  presents  himself  and  delivery  documents  at  the  gate. 

•  Documents  are  matched  against  system. 

•  Trucker  is  directed  to  parking  area  or  unloading  dock  at  terminal. 

•  Equipment/cargo  is  received. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Terminal  sends  arrival  notice  to  related  parties. 

6.4  Highway  Departure 

•  Terminal  receives  pickup  instructions  from  the  Consignee. 

Transaction  sets: 

o  Load  Tender,  EDI  204; 
o  Response  to  a  Load  Tender,  EDI  990; 
o  Transportation  Status,  EDI  214. 

•  Trucker  books  pickup  appointment  (Web  Interface  or  EDI). 

•  Trucker  presents  himself,  delivery  documents  and  pickup  reference  at  the  gate. 

•  Documents  are  matched  against  system. 

•  Equipment/  cargo  is  released. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 
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•  Terminal  sends  release  notice  to  related  parties. 

6.5  Inbound  Rail 

•  The  Terminal  receives  Shipment  information  from  the  Rail  Carrier  or  Consignor. 
Transaction  sets: 

o  Bill  of  Lading,  EDI  404; 
o  Rail  Waybill,  EDI  417. 

•  The  transport  status  and  progress  is  reported  via  status  messages. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322; 
o  Car  Location  Message,  NITL  CLM. 

•  Rail  Carrier  delivers  railcars  to  Terminal. 

Transaction  sets: 

o  Rail  Consist,  EDI  418. 

•  Arriving  equipment  is  automatically  matched  against  the  pre-advised  information. 

•  System  suggests  yard  parking  after  equipment  is  identified  based  on: 

o  Non-matching  equipment  is  marked  quarantined  for  investigation; 
o  Customs  hold/release  status  is  recorded  against  equipment  if  export; 
o  Special  handling  considerations  (Refrigerated,  HAZMAT,  etc.); 
o  Pre-advised  forwarding  instructions  from  Ocean  Carrier. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Terminal  sends  arrival  notice  to  related  parties. 

6.6  Outbound  Rail 

•  Consignor  (Terminal  or  Freight  Agent)  issues  Shipment  to  Rail  Carrier. 
Transaction  sets: 

o  Bill  of  Lading,  EDI  404. 

•  Rail  Carrier  accepts  shipment  and  generates  a  Rail  Waybill. 

Transaction  sets: 

o  Rail  Waybill,  EDI  417. 

•  Terminal  plans  the  train  loading  and  generates  work  orders. 

•  Rail  Carrier  releases  empty  railcars  Terminal. 

•  Terminal  loads  railcars. 

Transaction  sets: 

o  Terminal  Operations  Activity,  EDI  322. 

•  Rail  Carrier  pulls  railcars  from  Terminal. 

Transaction  sets: 

o  Rail  Consist,  EDI  418. 
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Figure  9:  EDI  Inbound  to  Port 
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7.0  Conclusion 

This  ITS  design  document  identifies  the  technical  and  functional  requirements  for  developing, 
procuring,  and  integrating  components  of  a  dual-use  ITS  capable  of  supporting  an  inland 
regional  port,  multi-modal  operating  software  system.  As  intended,  this  document  does  not 
identify  all  the  systems  that  will  compose  the  end  state  deployment  of  the  ITS  or  multi-modal 
operating  system.  However,  this  design  document  does  support  the  initiation  of  the 
development,  deployment,  and  testing  of  an  ITS  based  on  a  Service  Oriented  Architecture 
(SOA).  At  the  beginning  of  the  next  project  year,  the  design  established  in  this  document  will  be 
developed  and  tested  through  a  cooperative  effort  with  Dole  Foods,  the  fifth  largest  importer 
through  the  Ports  of  Long  Beach  and  Los  Angeles.  SM21  will  integrate  the  Dole  Foods  supply 
chain  distribution  network  through  Southern  California.  Together,  SM21  and  Dole  Foods  will 
conduct  a  number  of  experiments  designed  to  support  the  testing  and  refinement  of  the  ITS 
design.  Additionally,  the  ITS  design  will  support  experimentation  associated  with  military  force 
deployment.  Specifically,  the  ITS  will  support  the  pending  force  deployment  demonstration 
associated  with  the  CCDoTT  Agile  Port  System. 

The  ITS,  as  designed  to  support  of  the  JDDSP,  will  enable  efficient  dual-use  node  and  individual 
terminal  operations  by  supporting:  the  optimization  of  logistics  flows;  the  maintenance  of  desired 
productivity;  and  the  achievement  of  high  service  quality  to  strengthen  customer  relationships 
through  up  to  the  minute  visibility  of  shipments  and  quick  turn  times. 
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APPENDIX  A:  GLOSSARY 


Terminology 

Definition 

AAR 

Association  of  American  Railroads.  The  central  coordinating  and  research  agency 
of  the  American  railway  industry.  This  agency  deals  with  matters  of  common 
concern  in  the  whole  field  of  railroading  from  operations  to  public  relations. 

ACCESSORIAL 

CHARGE 

A  service  in  addition  to  the  line  haul  service,  usually  at  an  added  expense.  Charges 
incurred  to  provide  additional  services  at  the  time  of  pick-up  or  delivery  of  the 
container.  These  might  include  driver  assist  in  load  or  unload,  driver  waiting  time  to 
load  or  unload  past  free-time  provision  of  the  tariff,  equipment  rental  (fork  lift), 
blocking  or  bracing,  additional  stop-off  charges,  container  charges  etc. 

ACL 

Allowable  Cargo  Load.  The  amount  of  cargo  and  passengers,  determined  by 
weight,  cubic  displacement,  and  distance  to  be  flown,  that  may  be  transported  by 
specified  aircraft. 

ALL  WATER 

SERVICE 

(AWS)  Ocean  service  from  the  Far  East  to  the  East  Coast  of  the  U.S.  via  the 
Panama  Canal. 

BACK  HAUL 

The  movement  of  freight  (or  empty  equipment)  back  to  the  point  of  origin  in  a  lane 
of  little  or  no  demand  for  the  service. 

BAD  ORDER 

Something  is  wrong  with  the  equipment. 

BENEFICIAL  OWNER 

The  entity  that  actual  has  title  to  the  cargo  being  shipped. 

BILL  OF  LADING 

A  document  that  establishes  a  contract  between  a  shipper  and  a  transportation 
company  that  moves  freight  between  specified  points  for  a  specified  charge.  Usually 
prepared  by  the  shipper  on  forms  issued  by  the  carrier,  it  serves  as  a  document  of 
title,  a  contract  of  carriage  and  a  receipt  for  the  goods. 

BLOCKED  TRAIN 

Railcars  grouped  in  a  train  by  destination  so  that  segments  (blocks)  can  be 
uncoupled  and  routed  to  different  destinations  as  the  train  moves  through  various 
junctions.  Eliminates  the  need  to  break  up  a  train  and  sort  individual  railcars  at 
junctions. 

BOC 

Beneficial  Owner  of  the  Cargo.  The  entity  that  actually  owns  (has  title  to)  the  goods. 
See  Beneficial  Owner. 

BOOKING 

Recording  arrangements  for  the  movement  of  goods  by  ocean  or  stack  train. 

BRC 

Billing  Repair  Card.  A  detailed  record  of  repairs  performed  in  accordance  with 
AAR  Rule  83. 

BUNDLED  RATES 

Rates  that  include  all  costs  in  one  charge. 

CAPACITY 

PLANNING 

A  plan  which  measures  and  analyzes  the  ratio  of  units  required  versus  units 
available  for  a  given  time  period.  The  direct  planning  of  specific  units  to  specific 
loads. 

CARRIER 

An  individual,  company  or  corporation  engaged  in  transporting  goods. 

CBP 

U.S.  Customs  and  Border  Protection  of  the  Department  of  Homeland  Security. 

CHASSIS 

The  wheels  and  frame  assembly  that  supports  the  container. 
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CLAIM 

A  demand  made  upon  a  carrier  for  payment  on  account  of  loss  sustained  through  its 
negligence  or  accidental  damage  while  under  the  carrier’s  authority. 

CLM 

Car  Location  Movement.  A  railroad  record  movement  of  a  load. 

COFC 

Container  on  flatcar.  A  container  that  moves  on  a  flatcar  without  a  chassis. 

COMMODITY 

The  description  of  the  actual  goods  being  shipped. 

COMMON  CARRIER 

A  transportation  company  operating  under  a  Certificate  of  Convenience  and 
Necessity;  provides  service  to  the  general  public  at  published  rates. 

CONSIGNEE 

The  receiver  of  the  goods  being  shipped. 

CONSIGNOR 

A  person  or  company  shown  on  the  bill  of  lading  as  the  shipper. 

CONTAINER 

A  piece  of  equipment  that  has  a  removable  chassis.  Usually  used  in  ocean  carriage 
or  on  stack  trains.  Comes  in  various  sizes:  20’,  40’,  45’,  48’  and  53’. 

CONTAINER  POOL 

An  agreement  between  parties  that  allows  the  efficient  use  and  supply  of  containers. 
A  common  supply  of  containers  available  to  the  shipper  as  required. 

CONVENTIONAL 

SERVICE 

Containers  moving  on  conventional  flatcars  (COFC/TOFC)  owned  by  rail  carriers. 

CROSS-TOWN 

A  truck  movement  between  one  railroad  intermodal  ramp  and  another.  Utilized 
either  for  speed  or  because  the  two  railroads  don’t  have  a  connection. 

CUBE  OUT 

When  a  container  has  reached  its  volumetric  capacity  before  it  reaches  its  permitted 
weight  limit. 

CUT-OFF  TIME 

The  latest  time  that  a  container  may  be  delivered  to  a  rail  ramp  or  vessel  in  order  to 
be  accepted  for  the  scheduled  departure  time. 

CY 

Container  Yard.  A  place  where  chassis  and  container  equipment  is  stored. 

DEMURRAGE 

See  Per  Diem 

DERAMPED 

A  trailer/container  that  has  been  taken  off  a  railcar. 

DESTINATION 

The  place  where  the  carrier  releases  the  cargo  to  the  consignee  or  his  agent. 

DETENTION 

A  charge  by  a  vendor  after  a  specific  time  has  passed. 

DISPATCH 

Information  given  to  the  drayman  that  is  picking  up  a  load  at  origin  or  delivering  it 
at  destination. 

DIVERSION 

A  change  made  in  the  route  of  a  shipment  in  transit 

DOOR-TO-DOOR 

Through  transportation  of  a  container  and  its  contents  from  consignor  to  consignee 

DOUBLE  STACK 

Refers  to  placing  one  container  on  top  of  another  container  in  a  double  stack  railcar 
for  onward  movement. 

DRAYAGE 

The  truck  portion  of  an  intermodal  movement. 

DRAYMAN 

A  carrier  who  provides  pick-up  and  deliveries  via  truck  to  and  from  the  rail  yard. 

DRIVER  ASISST 

When  the  driver  is  required  to  load  or  unload  a  shipment. 

DROP 

The  driver  leaves  the  trailer  at  the  customer’s  facility  and  picks  it  up  after  it  is 
loaded  or  unloaded. 

DRY  FREIGHT 

Dry  cargo  not  requiring  temperature  control  protection 
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DST 

Double  Stack  Train.  Refers  to  the  practice  of  placing  one  container  on  top  of  another 
in  a  special  railcar  for  movement.  See  double  stack. 

EARLY  WARNING 

A  directive  issued  by  the  AAR  for  interchange  freight  cars  having  mechanical  or 
potential  safety  problems. 

EDI 

Electronic  Data  Interchange;  The  exchange  of  information  via  computer. 

EIR 

Equipment  Interchange  Receipt.  A  form  used  by  parties  delivering  or  receiving 
containers  or  container  equipment.  Used  for  equipment  control  and  damage  liability 
purposes.  Synonymous  with  TIR  (Trailer  Interchange  Receipt) 

EMPTY  REPO 

Empty  repositioning.  The  movement  of  empty  containers  by  rail  or  truck  to  meet 
service  requirements  elsewhere. 

EMPTY  SLOT 

An  available  loading  position  on  a  stack  car  created  when  a  container  isn’t  loaded  to 
an  available  position.  Also  known  as  a  vacant  slot. 

EN-ROUTE 

In  transit  to  destination. 

ETA 

Estimated  Time  of  Arrival  of  a  load. 

FAK 

Freight  All  Kinds;  A  generic  term  for  any  kind  of  freight. 

FCL 

Full  Container  Load 

FEU 

Forty- foot  Equivalent  Unit. 

FLATCAR 

A  railcar,  which  a  trailer/container  is  placed  on  to  move  via  the  railroad.  A  car 
without  roof  or  walls. 

FLIP 

When  a  container  is  picked  up  off  of  the  ground  and  mounted  on  a  chassis  for  street 
or  highway  transport. 

FRA 

Federal  Railroad  Administration.  The  FRA  deals  specifically  with  transportation 
policy  as  it  affects  the  nation’s  railroads  and  is  responsible  for  enforcement  of  rail 
safety  laws. 

FREE  TIME 

The  amount  of  time  allowed  by  the  carriers  for  the  loading  or  unloading  of  freight 
before  charges  begin  to  accrue. 

FREIGHT 

Refers  to  either  the  cargo  carried  or  the  charges  assessed  for  the  carriage  of  the 
cargo. 

FREIGHT  BILL 

A  document  issued  by  the  carrier  based  on  the  bill  of  lading  and  other  information; 
used  to  account  for  a  shipment  operationally,  statistically,  and  financially. 

FREIGHT 

FORWARDER 

A  company  that  arranges  for  the  movement  of  import  and  export  shipments.  Also 
prepares  all  necessary  U.S.  Customs  documentation. 

FTZ 

Foreign-Trade  Zone.  A  restricted-access  site,  authorized  by  the  FTZ  Board  and 
supervised  by  CBP  (19  CFR  146)  where  companies  can  use  special  Customs 
procedures  prior  to  entry  for  consumption.  Zones  are  located  in  or  adjacent  to  a  CBP 
port  of  entry  and  operated  pursuant  to  public  utility  principles  under  the  sponsorship 
of  a  corporation  granted  authority  by  the  Board  pursuant  to  the  Foreign-Trade  Zones 
Act  (19  USC  81a-81u)  and  regulations  (15  CFR  Part  400). 

GATE 

A  point  at  an  intermodal  terminal  where  a  clerk  checks  in  and  out  all  containers  and 
trailer.  All  reservations  and  paperwork  are  checked  at  the  gatehouse. 

GENSET 

Generator  used  to  regulate  temperature  in  a  reefer  container;  can  be  run  on  its  own 
power  or  plugs  provided  at  the  storage  area. 
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GROSS  WEIGHT 

Combined  weight  of  cargo  and  container  ready  for  shipment. 

HAZMAT 

Hazardous  Material.  Product  that  is  determined  to  be  harmful  and  requires  special 
handling  as  set  forth  by  government  agencies  and  the  intermodal  companies. 

HOSTLER 

An  individual  employed  to  move  containers  and  trailers  within  a  terminal  or 
warehouse  yard  area. 

IANA 

Intermodal  Association  of  North  America.  An  industry  trade  association 
representing  the  combined  interests  of  intermodal  freight  transportation  companies. 

ICC 

Interstate  Commerce  Commission.  A  federal  regulatory  agency  that  governed  over 
the  rules  and  regulations  of  the  railroading  industry.  The  ICC  Termination  Act  of 
1995  ended  this  regulatory  agency.  Most  responsibilities  were  transferred  to  the 
Surface  Transportation  Board. 

IMC 

Intermodal  Marketing  Company.  An  intermediary  in  the  movement  of  intermodal 
shipments.  See  Third  Party. 

IN-BOND 

A  shipment  that  is  moving  but  has  not  cleared  U.S.  Customs.  The  clearing  of  U.S. 
Customs  will  occur  at  destination. 

INBOUND 

Cargo  moving  from  a  rail  terminal  towards  its  destination.  Generally  used  for  cargo 
coming  off  a  train  and  heading  for  final  delivery  to  consignee. 

IN-GATE 

The  transaction  or  interchange  that  occurs  at  the  time  a  container  is  received  by  a 
rail  terminal,  container  yard,  or  water  terminal  from  another  carrier. 

INTERCHANGE 

The  exchange  of  railcars  between  connecting  railroads. 

INTERLINE 

Between  two  or  more  transportation  companies. 

IPI 

Inland  Point  Intermodal.  A  shipment  booked  and  moved  from  foreign  origin  port  to 
U.S.  inland  destination  for  one  quoted  charge  by  the  steamship  line. 

ISO 

International  Organization  for  Standardization 

J-l 

A  report  filled  out  during  the  in-gate  and  out-gate  process.  The  J-l  details  damage  to 
the  unit,  container  information,  shipping  information,  drayman  involved  and  time  of 
in-gate/  out-gate. 

JOB  CODE 

A  4  digit  number  that  identifies  the  inspection,  repair,  and /  or  testing  performed,  or 
the  car  component  applied  or  removed. 

LADING 

Refers  to  the  freight  shipped;  the  contents  of  a  shipment. 

LIFT 

The  process  of  moving  a  container  or  trailer  to  and  or  from  a  rail  car. 

LINE  HAUL 

The  movement  of  freight  via  railroad  from  one  city  to  another. 

LIVE  LOAD 

The  driver  stays  with  a  load  while  it  is  being  loaded  or  unloaded. 

LOCAL  CARGO 

Cargo  that  is  booked  from  a  foreign  port  to  a  U.S.  port  with  no  inland  movement  of 
the  freight  by  the  steamship  line. 

LTL 

Less  Than  Truckload.  A  shipment  that  would  not  by  itself  fill  the  truck  to  capacity 
by  weight  or  volume. 

M&R 

Maintenance  and  Repair.  The  process  of  maintaining  equipment  in  good  repair  and 
serviceability. 

MARINE  TERMINAL 

The  facility  where  cargo  is  discharged  from  and  loaded  to  the  ocean  vessel. 
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MHE 

Materials-Handling  Equipment.  Mechanical  devices  for  handling  cargo. 

NET  WEIGHT 

Weight  of  the  cargo  alone,  without  any  immediate  wrappings. 

NOTIFY  PARTY 

The  party  that  is  notified  at  the  time  a  container  or  trailer  is  grounded  from  a  train. 
Most  notify  parties  are  draymen. 

NVOCC 

Non  Vessel  Operating  Common  Carrier.  A  company  that  buys  wholesale  space  on 
steamship  lines  and  resells  the  space  to  individual  shippers  at  a  profit. 

OCP  CARGO 

Overland  Common  Point.  Refers  to  cargo  that  is  handled  by  the  steamship  line  only 
to  a  U.S.  port  of  entry.  The  shipper  or  consignee  then  plans  to  move  the  cargo  inland 
(east  of  the  Rockies)  at  their  expense. 

OD  PAIR 

Origin  /  destination  locations  identified  in  a  tariff  rate  structure. 

ON-DOCK 

Refers  to  the  process  whereby  cargo  from  the  ocean  vessel  is  loaded  to  railcars 
within  the  marine  terminal. 

ORIGIN 

Location  where  shipment  begins  its  movement  at  cargos  expense. 

OUTBOUND 

Cargo  moving  from  a  shipper  to  rail  ramp.  Generally  refers  to  cargo  going  onto  a 
stack  or  conventional  train. 

OUT-GATE 

The  transaction  or  interchange  that  occurs  at  the  time  a  container  is  delivered  from  a 
rail  terminal,  CY,  or  water  terminal  to  another  carrier. 

OVER-THE-ROAD 

(OTR) 

An  all  truck  freight  shipment,  used  in  lieu  of  rail  service,  at  a  premium  charge. 

OWNER  CODE 
(SCAC) 

Standard  Carrier  Abbreviation  Code  identifying  the  carrier  -  drayman,  steamship 
line  etc. 

PALLET 

A  wooden,  paper  or  plastic  platform  usually  with  a  top  and  bottom,  on  which 
packaged  goods  are  placed  to  facilitate  movement  by  some  type  of  freight  handling 
equipment. 

PER  DIEM 

Additional  charges  to  the  shipper  or  consignee  for  a  carrier’s  equipment  past  the  free 
time  provisions  of  the  equipment  interchange  contract  while  the  equipment  remains 
in  the  possession  of  the  shipper  or  consignee. 

PICK-UP 

The  act  of  calling  for  freight  by  truck  at  the  consignors  shipping  platform. 

PICK-UP 

APPOINTMENT 

Scheduled  time  for  pick-up  or  loading  of  a  container  from  a  shipper  or  consignee. 

PICK-UP  NUMBER 

A  secure  number  provided  to  parties  listed  on  the  waybill.  It  allows  only  those 
parties  to  receive  a  container  in  order  to  out-gate  from  ramp  facilities. 

POD 

Proof  of  Delivery.  A  form  signed  by  the  consignee,  proving  the  load  has  been 
delivered. 

POOL 

A  group  of  equipment  at  a  customer’s  facility  for  them  to  load  at  their  convenience. 

PRENOTE 

Information  sent  to  the  delivering  carrier,  telling  where,  when  and  how  to  deliver  a 
load. 

RAIL  GROUNDING 

The  time  that  the  container  was  discharged  (grounded)  from  the  train. 

RAIL  NOTIFICATION 

Notification  to  the  Notify  Party  that  the  container  has  been  discharged  from  the  train 
and  is  available  for  pick-up. 
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RAIL  RAMP 

The  location  where  the  draymen  pick  up  and  deliver  loads  to  the  railroad,  and  where 
trains  are  loaded  or  discharged. 

RAMP 

A  technical  rail  ramp  not  serviced  by  an  actual  train. 

RAMPED 

A  trailer/container  that  has  been  placed  on  a  railcar. 

REVENUE  LOAD 

A  load  of  freight  for  which  freight  charges  are  applied. 

REVENUE  WAYBILL 

A  waybill  showing  the  amount  of  charges  due  on  a  shipment. 

RULE  11 

A  railroad  accounting  term  which  refers  to  a  customer  shipping  their  freight  "pre¬ 
paid"  to  an  intermediate  point  and  "collect"  beyond  that  intermediate  point  to  the 
final  destination. 

SCAC 

See  Owner  Code. 

SEAL 

Something  applied  to  the  outside  of  equipment  doors  after  loading  to  assure  the  load 
has  not  been  tampered  with. 

SERVICE  FAILURE 

When  the  actual  delivery  exceeds  the  customer’s  expectations  by  a  specific  amount 
of  time. 

SERVICE  ORIENTED 
ARCHITECTURE 

An  architecture  that  relies  on  service-orientation  as  its  fundamental  design  principle. 

SHIPMENT 

The  tender  of  one  lot  of  cargo  at  one  time  from  one  shipper  at  one  location  to  one 
consignee  at  one  destination,  on  one  bill  of  lading. 

SHIPPER 

The  actual  party  tendering  a  load  of  freight. 

SHIPPING  ORDER 

Instructions  of  shipper  to  a  carrier  for  forwarding  of  goods. 

SHORING 

A  system  of  horizontal  and/or  inclined  structural  members  fastened  to  the  piles  of  a 
bent,  group  or  row  to  increase  stability  by  resisting  or  distributing  lateral  forces  to 
the  structure.  Similar  to  bracing. 

SLOT  UTILIZATION 

The  method  of  utilizing  every  space  available  on  a  double  stack  car.  A  slot  includes 
the  space  above  a  container  when  another  container  can  be  double-stacked.  A  five 
platform  double  stack  car  has  10  slots  available  for  loading.  If  all  10  slots  are 
loaded,  you  have  100%  slot  utilization. 

SPOTTING 

Placing  a  container  where  required  to  be  loaded  or  unloaded 

STACK  CAR 

An  articulated  five  or  three-platform  railcar  that  allows  containers  to  be  double 
stacked. 

STACK  TRAIN 

A  dedicated  train  that  hauls  containers  stacked  two  high. 

STAY  WITH 

Type  of  drayman  service  whereby  the  driver  remains  with  the  freight  while  the 
shipper  or  consignee  loads  or  unloads. 

STCC 

“Standard  Transportation  Commodity  Code.  A  method  of  identifying  products  or 
commodities  using  standardized  numeric  codes. 

STORAGE  CHARGES 

See  Demurrage/  Per  Diem. 

SURCHARGE 

An  extra  or  additional  charge. 

TARE  WEIGHT 

The  weight  of  packing  material,  or  in  railcar  or  container  shipments,  the  weight  of 
the  empty  railcar  or  empty  container. 

TARIFF 

A  publication  setting  forth  the  charges,  rates  and  rules  for  transportation  companies. 
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TENDER 

The  offer  of  goods  for  transportation  or  the  offer  to  place  cars  or  containers  for 
loading  or  unloading. 

TERMINAL 

An  assigned  area  in  which  containers  are  prepared  for  loading  onto  a  train  or  are 
stored  after  discharge  from  a  train. 

TERMINAL  CHARGE 

A  charge  made  for  services  performed  in  a  carrier’s  terminal  area. 

TEU 

Twenty-foot  Equivalent  Unit.  A  standard  container  size  used  for  comparative 
measuring  purposes.  Normally  applied  to  containers  used  by  steamship  lines  (20,  40 
and  45  foot  containers) 

THIRD  PARTY 

Refers  to  an  intermediary,  which  arranges  for  the  movement  of  intermodal 
shipments. 

THIRD  PARTY 
INTERNATIONAL 

An  ocean  shipping  company 

TOFC 

Trailer  On  Flat  Car.  A  trailer  that  moves  on  a  flat  car  with  the  chassis  attached. 

TRAILER 

A  freight  vehicle  equipped  with  a  permanent  wheel  assembly  and  a  device  for 
attaching  to  a  tractor  for  movement. 

TRAILER 

INTERCHANGE 

Transfer  of  a  trailer  and  lading  from  one  carrier  to  another. 

TRAIN  ID 

A  system  to  identify  the  trains  origin  and  destination  points,  the  day  of  the  week  for 
departure  and  the  week  of  the  year  it  moved. 

TRANS  PACIFIC 

Import/export  water  service  to  and  from  the  West  Coast  ports  to  and  from  Far  East 
ports. 

TRANSIT  TIME 

The  actual  amount  of  time  for  a  load  to  move  from  point  of  origin  to  delivery  at 
destination. 

TRANSLOAD 

The  transferring  of  product  from  one  piece  of  equipment  to  another. 

UMLER 

Universal  Machine  Language  Equipment  Register.  A  computer  readable  file  of  vital 
statistics  for  each  railroad  car  in  service.  It  applies  to  all  railroads,  types  of  cars,  and 
data  processing  machines. 

UNBUNDLED 

A  product  that  will  have  separate  charges  for  each  activity  accorded  to  the  shipment 

UNIT  TRAIN 

A  train  of  a  specified  number  of  railcars,  which  remain  as  a  unit  for  a  designated 
destination  or  until  a  change  in  routing  is  made. 

WASTE  CUBE 

A  container  with  empty  space.  May  result  when  the  weight  load  is  reached  before 
the  volumetric  limit. 

WAYBILL 

A  document  prepared  by  a  transportation  line  at  the  point  of  a  shipment;  shows  the 
point  of  origin,  destination,  route,  consignor,  consignee,  description  of  shipment  and 
amount  charged  for  the  transportation  service.  A  waybill  is  forwarded  with  the 
shipment  or  sent  by  mail  to  the  agent  at  the  transfer  point  or  waybill  destination. 
Unlike  a  bill  of  lading,  a  waybill  is  not  a  document  of  title. 

WHY  MADE  CODE 

Numeric  code  used  to  designate  the  reason  repairs  or  services  were  made  or 
performed. 

YARD 

A  classification,  storage  or  switching  area. 
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APPENDIX  B:  REFERENCES 

1.  Advent  Inc,  Advent  Terminal  Operating  System  (TOS),  www.adventinc.com 

2.  Canadian  National,  Intermodal  Terminal  Management  System  (ITMS),  www.cn.ca 

3.  Cargo  Data  Management  Corp,  Station  Track  II,  www.cargodata.com 

4.  Central  Systems  &  Automation  Ltd,  Autostore  Container  Terminal  Management  System 
(CTMS),  www.central-systems.co.uk 

5.  CMC  Limited,  Marine  Container  Handling  System,  www.cmcltd.com 

6.  COSMOS,  COSMOS  Terminal  Systems,  www.cosmos.be 

7.  CSX,  Intermodal  Terminal  Operations  System  (ITOPS),  www.csxi.com 

8.  Embarcadero  Systems  Corporation,  Computer  Automated  Terminal  Operation  System 
(CATOS);  Premier  Appointment  System  (PAS),  www.esvstem.com 

9.  eOPS  Inc,  eTERM,  www.etermsys.com 

10.  Hamburg  Port  Consulting,  Container  Terminal  Information  System  (CTIS), 
www.hamburgportconsulting.de 

1 1 .  IBS  Software  Services,  iLogistics,  www.ibsplc.com 

12.  IntelliTrans  LLC,  Global  Visibility  Platform  (GVP);  Material  Management  System 
(M2S),  www.intellitrans.com 

13.  Kale  Consultants  Ltd,  MERCURY,  www.kaleconsultants.com 

14.  Maher  Terminals  Logistic  Systems,  MTLS  Container  Terminal  Management  System, 
www.mtls.co 

15.  Mercator,  Chameleon,  www.mercator.com 

16.  Navis,  SPARCS  Terminal  Operating  System,  www.navis.com 

17.  Oasis  Reference  Model  for  Service  Oriented  Architecture  1.0,  Public  Review  Draft  1.0, 

10  February  2006 

18.  Optimization  Alternatives,  Optimization  Alternatives'  Strategic  Intermodal  Scheduler 
(OASIS);  Yard  Hawk,  www.oax.com 

19.  Sabre  Airline  Solutions,  CargoMax,  www.sabreairlinesolutions.com 

20.  Softship,  Terminal  Management  System  (TMS),  www.softship.com 

21.  TranCore  3sity  Global  Visibility  Platform  Design  Overview  Documentation 

22.  Virtual  Yard  Management  Inc.,  KT3  Yard  Management  System  (YMS),  www.vyminc.com 
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